Linking Dynamics Resources

[JoPe72]

This is not as much an issue as it is a discussion...

I have been thinking for a while about what is the best way to give Visual Studio access to Dynamics 365 FO DLL resources.

Today the D365FOAdminToolkitNET.csproj file contains relative links to the DLLs, suitable for a cloud hosted dev environment. This means that all the links point to the AOSService folder. When developing on a UDE the path to the DLLs is probably not correct since everyone os cloning the repo to different paths.

I am not a .NET dev so I do not really know how this is usually done, I also see that in most cases this is done by getting a .nuget package. I have not found a nuget package for the Dynamics assets and I have thought about how this can be mitigated.

My thought is that if we create a SymLink to "PackagesLocalDirectory\bin" in the Packages Folder, thar might work

new-item -itemtype symboliclink -path "$RepoBasePath\Project\D365FOAdminToolkit\packages\" -Name "DynamicsBin" -Value "$PackagesLocalDirectoryPath\bin"

However... the issue here is that creating SymLinks requires an elevated command prompt. Another option is to copy the files to a folder in Packages. Then we have to adjust the script every time we add dependencies.

Please let me know if you like any of the solutions or if you have another idea

[jofme]

I wonder if it's better if we added conditions to the .csproj file? Don’t have access to a UDE environment so I’m unable to test this.

In D365FOAdminToolkitNET.csproj:

<ItemGroup Condition="Exists('..\foo\bar')"> <!-- UDE Environment -->
    <Reference Include="Microsoft.Dynamics.XXX">
      <HintPath>****\bin\Microsoft.Dynamics.AX.Metadata.Core.dll</HintPath>
    </Reference>
    <Reference Include="Microsoft.Dynamics.Security.XXX">
      <HintPath>****\bin\Microsoft.Dynamics.AX.Metadata.Security.dll</HintPath>
    </Reference>
</ItemGroup>

<ItemGroup Condition="Exists('..\bas')"> <!-- CHE Environment -->
    <Reference Include="Microsoft.Dynamics.XXX">
      <HintPath>****\bin\Microsoft.Dynamics.AX.Metadata.Core.dll</HintPath>
    </Reference>
    <Reference Include="Microsoft.Dynamics.Security.XXX">
      <HintPath>****\bin\Microsoft.Dynamics.AX.Metadata.Security.dll</HintPath>
    </Reference>
</ItemGroup>

https://learn.microsoft.com/en-us/visualstudio/msbuild/itemgroup-element-msbuild?view=vs-2022

[jofme]

Hmm... Another thought... @JoPe72 is it completely insane if we had a PowerShell script manipulate the .csproj file?

[FH-Inway]

Interesting topic, not just for the D365FOAdminToolkit. Over at d365fo.tools, we are also wondering how to handle UDE.

I like @jofme 's idea to handle it with the MSBuild capabilities provided by the .*proj files. I did a bit of tinkering with that in #12 when I tried to account for different paths to the .dlls on a development environment and on a build agent.

I think for UDEs, this needs to be more sophisticated. While I'm predisposed towards PowerShell, I think it would be better to have the logic in the .csproj file, rather than modifying it from outside. One think to keep in mind: On UDEs, there can be multiple configurations for different versions of FO and/or different environments the customizations are deployed to. There seem to be registration values under Computer\HKEY_CURRENT_USER\Software\Microsoft\Dynamics\AX7\Development\Configurations that hold the information of the currently active configuration. The idea is to use the MSBuild Get RegistryValue command to get the FrameworkDirectory value. If there is one, good, we can probably use that to figure out the path to the .dlls. If not, we are probably on a local VHD or CHE environment and can use the already existing paths.

[jofme]

I agree, I haven’t faced this issue before (we didn’t really use UDE at my former job due to cost). I expect the community to encounter this more often as more customers transition to UDE developer environments.

[ameyer505]

I think this is a fantastic discussion to have as it will impact basically any ISV or partner that is developing code especially across teams.

I am actually in a unique position as I currently have access to all 3 types of environments, so I can help test this out.

For CHE and VHD's we have a fairly known path (K:\AosServices\PackagesLocalDirectory\bin for CHEs and C:\AosServices\PackagesLocalDirectory\bin for VHDs)

As @FH-Inway pointed on UDEs are going to be slightly trickier as the metadata version info is a part of the path (eg: C:\Users\\AppData\Local\Microsoft\Dynamics365\\PackagesLocalDirectory\bin) but if we can query the registry somehow that might work (not sure what permissions would be needed to do this).

I do think that whatever solution we come up with will absolutely help the community!

Also learn something new everyday, had no idea you could put condition logic in the csproj file!