Should System.Collections.Immutable and System.Threading.Tasks.Dataflow be supported? #38
Comments
|
Yes, I think we should do this--same underlying cause as NuGet/Home#6918. |
|
Oops, I was wrong I didn't actually fix the issue with what I did (still had the Microsoft.Build assemblies in the app directory). We have a .NET framework build application that references Microsoft.Build assemblies for building our projects (big pile of 452 and 471 .NET framework projects). The build application currently only works if several DLLs from the MSBuild bin directory (Microsoft.Build assemblies, System.Threading.Tasks.Dataflow, System.Collections.Immutable) are dropped into the application directory and the VSINSTALLDIR and VisualStudioVersion environment variables are set. I thought this was lame so I reworked it to use MSBuildLocator to detect the Visual Studio instance and resolve the assemblies from the MSBuild bin folder. After the changes (and removing the environment variables and assemblies from the application directory), building WPF projects (even a hello world project) trigger a Microsoft.WinFx.targets error MC1000: Unknown build error, 'Object reference not set to an instance of an object.' error. The logger events indicate it's happening during the MarkupCompilePass1 task. Any suggestion on how to further troubleshoot this or what would be a more appropriate forum for the issue? |
|
it's weird, I reduced our program down to just setting up a ConsoleLogger, loading a Project, and calling Project.Build. If I drop the Microsoft.Build DLLs into the application directory it works. If I rely on the assembly resolver to load the same DLLs from the MSBuild bin folder it fails with the unknown build error. |
|
working around the error by choosing a Visual Studio instance and copying assemblies from the MSBuild bin folder to the application folder before doing anything that would load those assemblies |
Do not error if some assemblies were already loaded: Changes the check for previously loaded assemblies to only fail if we already registered them via MSBuildLocator. Then adds previously loaded assemblies to the list of loaded assemblies so they aren't loaded again. Loads all assemblies in the MSBuild folder and doesn't throw an error if the assembly is already loaded. LoadedMsBuildAssemblies concept is important in ways I didn't think of when I suggested removing it. We still want the guardrail of "you have MSBuild next to your application/already loaded MSBuild assemblies before you called Register". Co-authored-by: Rainer Sigwald <raines@microsoft.com> Fixes #103. Also Fixes #38.
The Microsoft.Build assembly references the System.Collections.Immutable and System.Threading.Tasks.Dataflow assemblies, both living in the MSBuild build folder. I saw failures building WPF projects in our build application and I got around it by adding assembly resolving support for System.Collections.Immutable.
The text was updated successfully, but these errors were encountered: