Udostępnij za pośrednictwem

Known Issue: Relative path errors when using version control

  • Artykuł

Microsoft Dynamics AX 2012

 

OBSERVATIONS

  • Relative path errors occurring in customer deployments when referencing shared assemblies
  • Customers use a version control system like TFS to manage developer customizations
  • Errors occur when developer customizations are ported into stabilization/production environment

 

OVERVIEW

Unlike classes, forms, & queries, compiled C# assemblies cannot be merged across layers.  Instead, compiled assemblies are stored in layer specific locations.  With the version of the assembly located in highest layer being the one which is ultimately deployed to the SSRS server.

Figure #1 – illustrates management of C# assemblies *without* customizations

In the above example, the C# assembly (“Report.DLL”) includes a direct reference to the shared assembly that resides in the SYS layer. The direct reference to the shared assembly can only be resolved during run-time execution if they both reside in the same layer during compilation of the project. When customizations are made to C# business logic assemblies the layer management code kicks in promoting the object into a higher layer. However, when a version control system like TFS is used to manage environment updates the relocation of the shared assembly into the higher layer will be ignored if where the shared assembly is NOT also included in the source control project. The result is an inability for the customized C# assembly to resolve the reference to the shared library (“Shared.DLL”).

Figure #2 – error caused by promotion of C# assembly into the USR layer due to customizations

RESOLUTION

Essentially, you’ll need to promote the shared library into the USR layer to support the direct references. This can be achieved by simply adding the shared assembly to the customer’s source control project. In the case of TFS, select the shared assembly located in AOT under Visual Studio Projects\C Share Projects, right+click the node, and select Add to Source Control.  This will copy the shared assembly into the USR layer thus enabling the customized report assembly to resolve the direct reference during run-time execution.

Figure #3 – including shared assembly in source control elevates object into the USR layer

STEPS

1) Modify the shared assembly [SRSDrillThroughCommon]

      Example:   In the AOT, Right-Click and select Edit on "AOT\Visual Studio Projects\C Sharp Projects\SRSDrillThroughCommon".

  • Opens the assembly in VS2010
  • Make an innocuous change to DrillThroughCommonHelper.cs
    • Example: change a comment
    • Compile the project  -> You should see the item in bold in the Application Explorer
      • This indicates that the item has now been elevated to the VAR layer

2) Add the shared assembly to TFS

3) The shared assembly [SRSDrillThroughCommon] now resides in the VAR layer in TFS

NOTES

  • You MUST modify the shared assembly to promote it into the VAR layer *before* adding it source control.
  • Existing report projects containing references to the shared assembly will NOT be affected by this change.

Comments

  • Anonymous
    March 20, 2014
    Thanks for posting descriptions like these, TJ! This is very useful. :-)

  • Anonymous
    April 30, 2014
    The comment has been removed