Creating new ProjectCreator throws FileNotFoundException

[krafs]

Creating a new ProjectCreator throws a FileNotFoundException at runtime with the following message:

System.IO.FileNotFoundException: 'Could not load file or assembly 'Microsoft.Build, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.'

Steps to reproduce:

1. Create new C# .NET5 Console application.
2. Add <PackageReference Include="MSBuild.ProjectCreation" Version="4.0.1" /> to the project.
3. Add ProjectCreator.Create(); to Program.Main.
4. Run application.

I've tried it with a .NET472-project as well, with no success.

[jeffkl]

Sorry I didn't realize how poorly documented that part of the API is. MSBuildProjectCreator cannot ship with MSBuild assemblies and neither can your application. You will need to have the MSBuild assemblies loaded at runtime.

You can do one of the following:

1. If your class is a unit test, have it inherit from MSBuildTestBase to have things wired up correctly.
2. Manually attach the assembly resolve event handler in MSBuildAssemblyResolver.

public static class MyApp
{
    public static MyApp()
    {
        AppDomain.CurrentDomain.AssemblyResolve += MSBuildAssemblyResolver.AssemblyResolve;
    }
}

3. Use MSBuildLocator: https://github.com/Microsoft/MSBuildLocator

[krafs]

Alright! I got it working now.

Both approaches solved the issue. But inheriting from MSBuildTestBase also removes some environment variables. That's not done in solution 2. Is it not strictly necessary? Or does it become more of an issue when setting it up in CI/CD or something?

[jeffkl]

Great! Those environment variables are necessary if your projects end up using the .NET Core SDK and are set by MSBuildLocator as well.

https://github.com/microsoft/MSBuildLocator/blob/master/src/MSBuildLocator/MSBuildLocator.cs#L297-L299

[krafs]

So, the reason the environment variables are removed in MSBuildTestBase is because the project might also be using MSBuildLocator, or the .NET Core SDK, which would interfere with MSBuildAssemblyResolver?

[jeffkl]

There's some magic that will sort of automatically find these paths, and that magic is disabled if the environment variables are set.

The options are:

1. Don't set them and rely on the entry point (dotnet.exe) to set them (this doesn't always work)
2. Unset them and let the magic happen later (this seems to work much more reliably and is potentially future-proof)
3. Set them explicitly after you've determined what their values should be (this means if the magic ever changes, you have to as well)

[krafs]

I guess I'll go with 2 then :)
Thank you so much for the help! Much appreciated.

[jeffkl]

Thanks for reporting this, I've opened #96 to track getting the documentation updated.