Developing Microsoft Project Integration

This document gives instructions that is needed for the Microsoft Project Integration developments.

When to use this information:

Use this page when you do bug fixes in the integration or future enhancements.

Contents

• Prerequisites
• Source Files
• Code Corrections
• Provide Support For Translations
• Testing Microsoft Project Integration Add-In
• Building Click-Once setup
• Building MSI package
• Folder Hierarchy
• Translation Support
• Click-Once Setup versioning
• Handling versioning in support
• FAQ

Prerequisites

Following prerequisites needs to be installed in development machine according to work with the MSP add- in.

• Install Microsoft Visual Studio 2013. If you select custom option during the installation, make sure to include Microsoft Visual Studio 2010 tools for office.
• Install VS 2013 add-in from here. This is needed if you expect to create MSI setup.
• Install the relevant tool disk.
• Microsoft Project 2013.
• If you get a compilation error regarding Ribbon error, go to C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets  and change the version number 10 to 12  

• If you get a compilation error saying "Cannot find the certificate that matches the project system thumbprint. To sign the application and deployment manifests, open the Project Designer, click the Signing page tab, select an existing certificate, and try again"  right click on Ifs.Prjmsp.2010, then select properties and then create a test certificate 

Source File

Check out the PRJMSP component and place it inside the tool disk's workspace folder.

Code Corrections

Open Ifs.Prjmsp.2010.sln solution inside prjmsp\source\prjmsp\client\Ifs.Prjmsp.2010 You can find the common form controls and logic inside Ifs.Application.Prjmsp project. Modify any code according to the requirement and build the solution.

Provide Support For Translations

If the code correction needs a change in the language files do the following steps.

1. Open Ifs.Prjmsp.2010.sln solution right click on the Ifs.Application.Prjmsp project and click on Extract Localizable Strings to generate Ifs.Application.Prjmsp.resources.xml.
2. Create the Prjmsp.lng file using the normal procedure.

Testing Microsoft Project Integration Add-In

After you have done the code corrections you can test the add-in by running the Ifs.Prjmsp.2010.sln solution. If you need to check any translation issues you need to follow below steps.

1. Commit the modified code and language file.
2. Wait for a build in team server.
3. Run the external\prjmsp\CopySateliteAssemblies.exe to copy Satellite Assemblies from the team server. (screen shot of the CopySateliteAssemblies.exe is shown below.)
   1. Verify path to the Team Server Client Runtime Folder and the Project folder are correct.
   2. Click on the Download button to copy required dll's from the Team-Server to prjmsp\source\prjmsp\client\Ifs.Prjmsp.2010\ Ifs.Prjmsp.2010 folder to work translations properly.
       

   

4. Run the Ifs.Prjmsp.2010.sln and test the add-in.

Building Click-Once setup

1. Open solution Ifs.Prjmsp.2010.sln (prjmsp\source\prjmsp\client\Ifs.Prjmsp.2010).
2. Change The Version number in following places

           Properties of Ifs.Prjmsp.2010 Project-->Application-->Assembly information

           Properties of Ifs.Prjmsp.2010 Project-->publish-->Publish Version

           Properties of Ifs.Application.Prjmsp Project-->Application-->Assembly information

3. If a signed Click-Once setup is needed, then the technical representative needs to load the PFX file before publishing the setup.

   

4. Publish Solution to prjmsp\client\officeaddins\prjmspofficeaddin

Building MSI package

1. Open solution Ifs.Prjmsp.2010.sln (prjmsp\source\prjmsp\client\Ifs.Prjmsp.2010).
2. You will see 2 projects (Ifs.Prjmsp.2010.Setup32 and Ifs.Prjmsp.2010.Setup64)
3. Build both Ifs.Prjmsp.2010.Setup32  and Ifs.Prjmsp.2010.Setup64 projects.

   

4. MSI file will generated in to the relevant folder as below (Ex; For the 32bit project the MSI will be generated in prjmsp\source\prjmsp\client\Ifs.Prjmsp.2010\Ifs.Prjmsp.2010.Setup32\Debug folder).
5. The Generated MSI files will be copied automatically with a post build event to a relevant folder inside win32client as below (Ex; For the 32bit project the MSI will be copied to prjmsp\win32client\IFS Project Management Microsoft Project Add-In (32-bit)\Install folder).

   

Folder Hierarchy

Since translation of earlier version Microsoft Project Integration Add-In did not work properly for IFS Application 8, PRJMSP component was restructured.
Solution was uplifted to the .NET 4.5.2 from .NET 3.5 framework. The folder structure shown above is used inside the client folder in order to overcome the translation issues.

Two separate solutions were used:

• Ifs.Application.Prjmsp
  All the forms, business logic, data, and utility classes were placed inside this. IFS Application Forms project template was used to create project. Otherwise it is not possible to Extract Localizable Strings and generate Ifs.Application.Prjmsp.resources.xml which needs to create LNG file required for translations.
   
• Ifs.Prjmsp.2010
  Ifs.Application.Prjmsp was referenced to the Ifs.Prjmsp to make it easy for debugging and code corrections.
  
   

Translation Support

As mentioned above all the forms and business logic which needs translations support is placed inside Ifs.Application.Prjmsp. Since its using namespace Ifs.Application it is possible to extract localizable strings by RMB on the solution using Visual Studio and you can create the LNG file in normal way.
But currently there is no way to copy build satellite assemblies via tool disk. So we have to copy required DLLs to the satellite assemblies folder manually after a build taken place.
A small application called CopySateliteAssemblies.exe is provided to make the copying process easier. It will copy required DLLs to the satellite assemblies folder and to the bin folder if required by the developer.

Working with Fictive Language

To enable fictive language support

• Open MS Project, Go to "IFS Applications" tab
• Ctrl + Shift and click Settings. In the Settings screen you will see the check box "Check Localization", Check this and apply the settings  (This check box will be not there when you click Settings option without Ctrl + Shift)



• Re-start MS Project. Now you will see that the fictive language is in operation.
• To remove fictive language support, do the reverse

Click-Once Setup versioning

The version of any given Office Add-In will be its Click-Once deployment version where each of the version numbers will have a clear meaning:
ClickOnce deployment version:  M.m.b.r (Major.Minor.Build.Revision)
 

• The version of any given Office Add-In will be its Click-Once deployment version where each of the version numbers will have a clear meaning.

• Major: Target IFS Applications version 
• Minor: Update number
• Build: RnD Binary Patch number
• Revision: Reserved for internal development and customizations 
   

For example: 009.001.001.000

• 009.x.x.x IFS Applications 9
• x.001.x.x Update 1
• x.x.001.x Patch version 001
• x.x.x.000 Internal version 000

        The third (Build) and fourth (Revision) digits require further information:

• Build (Patch version): It should be lifted incrementally (+1) every time we need to deliver a binary patch. This number is not a bug id from LCS. Also, for a LCS bug delivering binary patches, we will need to specify the version delivered.
• Revision (Customization version): It should mainly be used for Consulting to indicate a customization. For instance, a version number 009.000.000.002 would indicate a CORE release, whilst a version number 009.001.000.002 would reflect a patch with 2 customizations. This number may also be used internally during the development/testing process, bearing in mind that, when something is delivered, the Build number should be lifted, and the Revision number should be reset to 0.

Handling versioning in support

• When promoting  any Microsoft Integration bug into InTest, include the ENTIRE VERSION NUMBER in the Deployment Notes in the component bug line
• Before patching any Application MSP bug
      Confirm whether the correct version number is specified in the Deployment Notes in the component line
      Confirm whether the latest version number (among all previously Patched bugs) is specified in the Deployment Notes in the component line
• In the event a bug to be patched do NOT have the latest version number (among all previously Patched bugs)
  • Reopen the bug

               With Reason Code "ADMINISTRATION"
               Description "Reopened to get the latest version setup installed in TQA"

  • Obsolete all files related to the existing version number
  • Regenerate MSP setup with the latest version number
  • Promote the bug into InTest and update Deployment Notes with the latest version number
     
• Technical Solutions Coordinator will keep track on the latest version number. In the event a bug needs to be reopened to get the correct version number, the software engineer who did the correction will need to obsolete the files, regenerate the MSP setup with the latest version number and put the bug into InTest.

Security

In the IFS Solution Manager, ensure activity handle "MspOperationManager" is granted to the permission-set "MSP_INTEGRATION" to run the MSP Integration. By default activity handle is granted to the permission-set "MSP_INTEGRATION". If the permission-set does not exist after installation it should be created manually (Run prjmsp\database\prjmsp\ POST_Prjmsp_MSPPermissionSet.sql).

To grant this permission set, only add the new permission-set toward the users that should be allowed access.

FAQ

1. How to roll back to an earlier version:

• Open the installation location of the Office solution.
•  In the top-level publish folder, delete the deployment manifest (the .vsto file).
•  Find the subfolder for the version you want to roll back to.
•  Copy the deployment manifest from that subfolder to the top-level publish folder.