jeffkl / msbuildprojectcreator Goto Github PK

View Code? Open in Web Editor NEW

44.0 44.0 5.0 498 KB

A fluent API for creating MSBuild projects for use by unit tests

License: MIT License

C# 100.00%

msbuildprojectcreator's Issues

Document how to handle resolving MSBuild assemblies

Reported in #95, need to update documentation on how to resolve MSBuild assemblies at runtime.

Let devs add their own library dll and/or arbitrary file to a package

I need to add a real DLL to a package instead of generating a dummy dll. I'm using PackageFeed to simulate loading of my package targets the same way a packagereference would do this. To do this i basically recreate the exact package.
This also means my build/PackageID.targets is already real so i wish could arbitrarily add my targets file using .File("build\PackageID.targets", "packageid.targets")
instead of having to do
.FileText("build/PackageID.targets", File.ReadAllText(Path.Combine(appDir, "build", "PackageID.targets")))

The proposed added APIs would look something like this:

public class PackageFeed : IDisposable
{
  public PackageFeed Library(string targetFramework, string filename = null, string @namespace = null, string className = null, string assemblyVersion = "1.0.0.0")
  public PackageFeed Library(NuGetFramework targetFramework, string filename = null, string @namespace = null, string className = null, string assemblyVersion = "1.0.0.0")
+ public PackageFeed Library(NuGetFramework targetFramework, string sourceFilePath)
...
  private PackageFeed File(string relativePath, Func<MemoryStream> streamFunc)
+ public PackageFeed File(string relativePath, string sourceFilePath)
}

Usage/Context

I discovered a bug in my package, tried to fix it, but discovered that the msbuild property i was now attaching to was being cleared by the SDK ("PrepareForRunDependsOn") - if i used my package as a regular nuget package this would have worked since nuget.g.targets is imported after that statement - now my generic Import statement produced with ProjectCreation ended up simulating a very different evaluation. PackageFeed comes in very handy to help me here by establishing the same nuget.g.targets evaluation as a real user would see it.

Tests requiring NuGetSdkResolver not working?

It seems Tests cannot resolve NuGet based Sdks, e.g. the Microsoft.Build.NoTargets (NuGet) Sdk.

This can be reproduced by adding the following test to BuildTests.cs:

        [Fact]
        public void CanUseNuGetSdkResolver()
        {
            ProjectCreator
               .Create(Path.Combine(TestRootPath, "project1.proj"))
               .ImportSdk("Sdk.props", "Microsoft.Build.NoTargets", "1.0.53")
               .ImportSdk("Sdk.targets", "Microsoft.Build.NoTargets", "1.0.53")
               .TryRestore(out bool result, out BuildOutput buildOutput);

            result.ShouldBeTrue();
        }

This fails with:

Message: 
    Microsoft.Build.Exceptions.InvalidProjectFileException : The SDK 'Microsoft.Build.NoTargets' specified could not be found.  C:\Users\japj\AppData\Local\Temp\02qqg4do.avw\project1.proj
  Stack Trace: 
    ProjectErrorUtilities.ThrowInvalidProject(String errorSubCategoryResourceName, IElementLocation elementLocation, String resourceName, Object[] args)
    ProjectErrorUtilities.ThrowInvalidProject[T1](IElementLocation elementLocation, String resourceName, T1 arg0)
    Evaluator`4.ExpandAndLoadImportsFromUnescapedImportExpressionConditioned(String directoryOfImportingFile, ProjectImportElement importElement, List`1& projects, SdkResult& sdkResult, Boolean throwOnFileNotExistsError)
    Evaluator`4.ExpandAndLoadImports(String directoryOfImportingFile, ProjectImportElement importElement, SdkResult& sdkResult)
    Evaluator`4.EvaluateImportElement(String directoryOfImportingFile, ProjectImportElement importElement)
    Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
    Evaluator`4.Evaluate(ILoggingService loggingService, BuildEventContext buildEventContext)
    Evaluator`4.Evaluate(IEvaluatorData`4 data, ProjectRootElement root, ProjectLoadSettings loadSettings, Int32 maxNodeCount, PropertyDictionary`1 environmentProperties, ILoggingService loggingService, IItemFactory`2 itemFactory, IToolsetProvider toolsetProvider, ProjectRootElementCacheBase projectRootElementCache, BuildEventContext buildEventContext, ISdkResolverService sdkResolverService, Int32 submissionId, EvaluationContext evaluationContext, Boolean interactive)
    ProjectImpl.Reevaluate(ILoggingService loggingServiceForEvaluation, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
    ProjectImpl.ReevaluateIfNecessary(ILoggingService loggingServiceForEvaluation, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
    ProjectImpl.ReevaluateIfNecessary(EvaluationContext evaluationContext)
    ProjectImpl.Initialize(IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
    Project.ctor(ProjectRootElement xml, IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectCollection projectCollection, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
    Project.ctor(ProjectRootElement xml, IDictionary`2 globalProperties, String toolsVersion, ProjectCollection projectCollection, ProjectLoadSettings loadSettings)
    ProjectCreator.TryGetProject(Project& project, IDictionary`2 globalProperties, String toolsVersion, ProjectCollection projectCollection, ProjectLoadSettings projectLoadSettings) line 69
    ProjectCreator.get_Project() line 39
    ProjectCreator.TryRestore(Boolean& result, BuildOutput& buildOutput, IDictionary`2& targetOutputs) line 332
    ProjectCreator.TryRestore(Boolean& result, BuildOutput& buildOutput) line 277
    BuildTests.CanUseNuGetSdkResolver() line 141

This is with VS2019 16.4.0

I don't know if the NuGetSdkResolver needs to be explicitly enabled, but since dotnet sdk projects seem to work fine, I don't understand why it is not working correctly out of the box.

System.IO.FileLoadException: Could not load file or assembly NuGet.Frameworks, Version=6.2.0.146

MSBuild.ProjectCreation: 8.0.0

Hello. I came across this library at the MSBuildSdks and started using it in an experimental project. Everything was working great until recently when my tests began to fail to build my generated projects when executing tests for the .NET 5 and .NET 6 target platforms (the test project targets those platforms). As far as I can tell, the issue comes up as soon as I install the more recent .NET 6 6.0.300 SDK on the machine. Seeing it on Windows, Linux, and MacOS. I currently target .NET Core 3.1, .NET 5, and .NET 6 in my test projects. The tests behave as expected for .NET Core 3.1, but fail with the following for .NET 5 and .NET 6 with the following output:

Target "ResolvePackageAssets" in file "C:\Program Files\dotnet\sdk\6.0.300\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets" from project "C:\Users\craig\AppData\Local\Temp\CentralBuildOutputTests\ct0vn00m.bwj\src\MyClassLibrary\MyClassLibrary.csproj" (target "ResolveLockFileReferences" depends on it):
Using "ResolvePackageAssets" task from assembly "C:\Program Files\dotnet\sdk\6.0.300\Sdks\Microsoft.NET.Sdk\targets\..\tools\net6.0\Microsoft.NET.Build.Tasks.dll".
Task "ResolvePackageAssets"
Unable to use package assets cache due to I/O error. This can occur when the same project is built more than once in parallel. Performance may be degraded, but the build result will not be impacted.
The "ResolvePackageAssets" task failed unexpectedly.
System.IO.FileLoadException: Could not load file or assembly 'NuGet.Frameworks, Version=6.2.0.146, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Could not find or load a specific file. (0x80131621)
File name: 'NuGet.Frameworks, Version=6.2.0.146, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
 ---> System.IO.FileLoadException: Could not load file or assembly 'NuGet.Frameworks, Version=6.2.0.146, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
   at System.Runtime.Loader.AssemblyLoadContext.LoadFromPath(IntPtr ptrNativeAssemblyLoadContext, String ilPath, String niPath, ObjectHandleOnStack retAssembly)
   at System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyPath(String assemblyPath)
   at Microsoft.Build.Shared.MSBuildLoadContext.Load(AssemblyName assemblyName)
   at System.Runtime.Loader.AssemblyLoadContext.ResolveUsingLoad(AssemblyName assemblyName)
   at System.Runtime.Loader.AssemblyLoadContext.Resolve(IntPtr gchManagedAssemblyLoadContext, AssemblyName assemblyName)
   at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheWriter.CanResolveApphostFromFrameworkReference()
   at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheWriter.WriteApphostsForShimRuntimeIdentifiers()
   at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheWriter.WriteItemGroup(Action writeItems)
   at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheWriter.WriteItemGroups()
   at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheWriter.Write()
   at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheWriter.WriteToMemoryStream()
   at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheReader.CreateReaderFromMemory(ResolvePackageAssets task, Byte[] settingsHash)
   at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheReader..ctor(ResolvePackageAssets task)
   at Microsoft.NET.Build.Tasks.ResolvePackageAssets.ReadItemGroups()
   at Microsoft.NET.Build.Tasks.ResolvePackageAssets.ExecuteCore()
   at Microsoft.NET.Build.Tasks.TaskBase.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask)
Done executing task "ResolvePackageAssets" -- FAILED.
Done building target "ResolvePackageAssets" in project "MyClassLibrary.csproj" -- FAILED.

full output.txt

I don't think my tests are doing anything overly complicated, but I've been wrong before. I haven't been able to workaround it on my dev machine. Even forcing it to use the 6.0.2xx version using the global.json didn't work. But, I was able to specifically install the 6.0.2xx SDKs on the build agents as a workaround for now and that did work, so i'm fairly certain it is the newer SDK.

Have you seen anything similar on your end? Any suggestions?

Referencing a local `.nupkg`

Hello 👋

I'm trying out this library for the first time, and I'm trying to figure out if there's an elegant way to take a local .nupkg file and add a PackageReference to it.

I'm looking at the API, and what I think I want is something roughly like this:

// some code to move a `MyPackage.1.0.0.nupkg` file into the rootPath directly.
// and then...
PackageFeed.Create(rootPath)
    .GetPackage("MyPackage", "1.0.0", out var package);

ProjectCreator
    .Templates.SdkCsproj()
    .ItemPackageReference(package)
    .Save();

Is there a good way to do this, or am I trying to do something that this library wasn't designed to do?

How to save a binlog for a build?

Would it be possible to save a binlog file of a build?
This would be useful for e.g. analysis of (unittest) build failures.

Question: How to use this for integration tests of a roslyn analyzer?

Hi, @jeffkl
The main question is how to add the exact dll into analyzers/dotnet/cs nupkg path.
Could you help me?

Could not load file or assembly 'NuGet.Frameworks, Version=6.2.1.7...

Me again. Getting the same issue as #170, but with a new version this time. Only this time there isn't a newer version of the NuGet.Frameworks package publicly available to force an update. The full version number of the dll in NuGet.Frameworks 6.2.1 is 6.2.1.2. So, there's a newer revision shipped somewhere that we can't get ahold of in a package. Not exactly sure which .NET SDK caused it, but 6.0.302 is currently exhibiting this behavior. I'm not sure I 100% understand the root cause of the problem, but i'd like to in order to drive the issue upstream. Either NuGet or the .NET SDK perhaps? Any suggestions?

TryBuild fails on plain sdk project build

The following

ProjectCreator.Templates.SdkCsproj("test.csproj", targetFramework: "netstandard2.0")
  .Save()
  .TryBuild(out var result, out var buildOutput);

fails with the following error:

Assets file 'D:\X\bin\Debug\net472\3226627f\obj\project.assets.json' not found. Run a NuGet package restore to generate this file.

I assume this happens because sdk-based builds require either a separate nuget restore or a msbuild /restore when building for the first time. dotnet build does wrap all that stuff already i assume.
I've been searching for ways to attach the /restore flag myself but Directory.Build.rsp fails and i see no option inside ProjectInstance etc. to run this as well.

Rebuilding project fails with duplicate generated AssemblyInfo

I'm not sure if this is an issue in this project, or in the SDK itself (or if I'm doing something wrong), so starting with an issue here to get your thoughts. Thanks in advance!

Repro steps

Create a simple SDK-style project
Add a reference to the NuGet API to allow restore
Try building the project, should succeed
Try building the project again, should succeed but fails

Here's a full repro case: https://github.com/MattKotsenas/repro-duplicate-assemblyinfo you should be able to just clone and dotnet test to repro the behavior.

Repro

Here's the interesting part of the repro:

public class UnitTest1 : MSBuildTestBase
{
    private readonly ITestOutputHelper _output;

    public UnitTest1(ITestOutputHelper output)
    {
        _output = output;
    }

    [Fact]
    public void Test1()
    {
        const string projectName = "ClassLibraryA";
        FileSystem fs = new();

        using (fs.CreateDisposableDirectory(out IDirectoryInfo temp))
        {
            Uri[] feeds = [ new Uri("https://api.nuget.org/v3/index.json") ];

            using (PackageRepository.Create(temp.FullName, feeds))
            {
                ProjectCreator projectCreator = ProjectCreator.Templates.SdkCsproj()
                    // Add this commented out code to prevent automatic generation of Assembly info and see the test pass.
                    //.Property("GenerateAssemblyInfo", "false")
                    .Save(Path.Combine(temp.FullName, projectName, $"{projectName}.csproj"));

                _output.WriteLine("Building for the first time:");
                projectCreator.TryBuild(restore: true, out bool firstResult, out BuildOutput firstOutput);
                Assert.True(firstResult, "This build should always succeed.");
                PrintAssemblyInfo(projectCreator);

                _output.WriteLine("Building for the second time:");
                projectCreator.TryBuild(restore: false, out bool secondResult, out BuildOutput secondOutput);
                PrintAssemblyInfo(projectCreator);
                Assert.True(secondResult, "This rebuild _should_ also succeed, but fails with duplicate version info.");
            }
        }
    }

    private void PrintAssemblyInfo(ProjectCreator projectCreator)
    {
        string objRelativePath = projectCreator.Project.GetPropertyValue("IntermediateOutputPath");
        string objFullPath = Path.GetFullPath(Path.Combine(projectCreator.Project.FullPath, "..", objRelativePath));

        string[] assemblyInfoFiles = Directory.GetFiles(objFullPath, "*AssemblyInfo.cs");

        if (assemblyInfoFiles.Length != 1)
        {
            throw new Exception($"Unable to determine AssemblyInfo.cs file. Found: {string.Join(", ", assemblyInfoFiles)}");
        }

        string contents = File.ReadAllText(assemblyInfoFiles.Single());

        _output.WriteLine("Contents of generated AssemblyInfo.cs:");
        _output.WriteLine(contents);
        _output.WriteLine("----------");
    }
}

Repro Output

Here's the output when I run the test:

 Repro.UnitTest1.Test1
   Source: UnitTest1.cs line 17
   Duration: 21.9 sec

  Message: 
This rebuild _should_ also succeed, but fails with duplicate version info.

  Stack Trace: 
UnitTest1.Test1() line 41
RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)

  Standard Output: 
Building for the first time:
Contents of generated AssemblyInfo.cs:
//------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated by a tool.
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------

using System;
using System.Reflection;

[assembly: System.Reflection.AssemblyCompanyAttribute("ClassLibraryA")]
[assembly: System.Reflection.AssemblyConfigurationAttribute("Debug")]
[assembly: System.Reflection.AssemblyFileVersionAttribute("1.0.0.0")]
[assembly: System.Reflection.AssemblyInformationalVersionAttribute("1.0.0")]
[assembly: System.Reflection.AssemblyProductAttribute("ClassLibraryA")]
[assembly: System.Reflection.AssemblyTitleAttribute("ClassLibraryA")]
[assembly: System.Reflection.AssemblyVersionAttribute("1.0.0.0")]

// Generated by the MSBuild WriteCodeFragment class.


----------
Building for the second time:
Contents of generated AssemblyInfo.cs:
//------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated by a tool.
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------

using System;
using System.Reflection;

[assembly: System.Reflection.AssemblyCompanyAttribute("ClassLibraryA")]
[assembly: System.Reflection.AssemblyConfigurationAttribute("Debug")]
[assembly: System.Reflection.AssemblyFileVersionAttribute("1.0.0.0")]
[assembly: System.Reflection.AssemblyInformationalVersionAttribute("1.0.0")]
[assembly: System.Reflection.AssemblyProductAttribute("ClassLibraryA")]
[assembly: System.Reflection.AssemblyTitleAttribute("ClassLibraryA")]
[assembly: System.Reflection.AssemblyVersionAttribute("1.0.0.0")]
[assembly: System.Reflection.AssemblyCompanyAttribute("ClassLibraryA")]
[assembly: System.Reflection.AssemblyConfigurationAttribute("Debug")]
[assembly: System.Reflection.AssemblyFileVersionAttribute("1.0.0.0")]
[assembly: System.Reflection.AssemblyInformationalVersionAttribute("1.0.0")]
[assembly: System.Reflection.AssemblyProductAttribute("ClassLibraryA")]
[assembly: System.Reflection.AssemblyTitleAttribute("ClassLibraryA")]
[assembly: System.Reflection.AssemblyVersionAttribute("1.0.0.0")]

// Generated by the MSBuild WriteCodeFragment class.


----------

Note that all the assembly attributes are duplicated.

Why it matters

In my case I'm authoring NuGet packages that add .props and .target files, and I wanted to build and rebuild to verify proper incremental build behavior. Today I'm working around the issue by setting GenerateAssemblyInfo to false in my test project.

TryBuild restore: true and using projectCollection causes Build to be not isolated from "Restore"?

Hi,

From inspecting the binlog of a failed testcase, it looks as if I am seeing the following problem:

Scenario:

csproj containing a PackageReference containing MSBuild targets/props
run TryBuild restore:true with a projectCollection

Result:

Build fails because it did not run the logic from the NuGet package targets/props

In the binlog I see only one project evaluation of the test project (the evaluation related to the Restore).
And I see the "build" targets underneath the tree of the Restore target instead of in its own project tree.

Since the Restore is generating NuGet.g.props/targets it means that when it runs the actual build it should do a re-evaluation of the test csproj file (since the global properties are different due to ExcludeRestorePackageImports), but that does not seem to happen.

Note this is something that I'm experiencing after upgrading to Visual Studio 2019 Update 11 from Update 9 (with
MSBuildProjectCreator 6.3.1)

I see that when no projectCollection is passed in Restore it will create a new collection, perhaps this is issue is related to that logic?

MSBuildProjectCreator/src/Microsoft.Build.Utilities.ProjectCreation/ProjectCreator.Build.cs

Line 532 in 881f1f6

    
           globalProperties ??= new Dictionary<string, string>(ProjectCollection.GlobalProperties);

As a workaround if I do

                    .TryBuild(target:"Restore", out result, out buildOutput) // workaround Restore isolation issue
                    .TryBuild(out result, out buildOutput);

Instead of

                     .TryBuild(restore: true, out result, out buildOutput);

It seems to work ok (i.e. no test failure)

binlog corrupt when build failed?

Hello,

Up until now the creation of binlog files has been succesfull.
However, I have a failed build and ran into an issue that the binlog file seems to be corrupt ("again").

.TryBuild(restore: true, target: "SomeTarget", out result, out buildOutput);

result is false (because of something I want to verify) and the binlog file only shows "Build failed" and no actual MSBuild content in the binlog viewer.

'Build' target (and .nuget.g.props) not included in binlog?

Hi again,

I am seeing some weirdness with package restore and binlog files (causing me some confusion when analyzing a totally different issue).

I made a testcase (based of an example in RepositoryTests.cs)

Basically this example is trying to:

confirm that PackageReference is actually consumed during a build
make a binlog of the whole process so I can do an analysis of what MSBuild is doing

However, the resulting binlog only shows the "Restore" target in the binlog, whereas I would also have expected a "Build" target in the binlog.

Also searching for PkgPackageA in the binlog does not get any hits, even though the ClassLibraryA.csproj.nuget.g.props contains it on disk.

This is tested with:

VS2022 17.0.6
MSBuildProjectCreator main branch

Note: in order to inspect the binlog file, you need to set a breakpoint to prevent automatic cleanup of the temp folder.

[Fact]
public void BuildCanConsumePackageWithGeneratePathProperty()
{
    string binLogPath = Path.Combine(TestRootPath, "test.binlog");

    using (PackageRepository.Create(TestRootPath)
            .Package("PackageB", "1.0", out Package packageB)
                .Library(TargetFramework)
            .Package("PackageA", "1.0.0", out Package packageA)
                .Dependency(packageB, TargetFramework)
                .Library(TargetFramework))
    {
        using (ProjectCollection projectCollection = new ProjectCollection())
        {
            projectCollection.RegisterLogger(new BinaryLogger
            {
                Parameters = $"LogFile={binLogPath}",
            });

            ProjectCreator.Templates.SdkCsproj(
                    path: Path.Combine(TestRootPath, "ClassLibraryA", "ClassLibraryA.csproj"),
                    targetFramework: TargetFramework,
                    projectCollection: projectCollection)
                .ItemPackageReference(packageA, metadata: new Dictionary<string, string>
                {
                    { "GeneratePathProperty", "true" },
                })
                .TryBuild(restore: true, out bool result, out BuildOutput buildOutput)
                .TryGetPropertyValue("PkgPackageA", out string packagePath);

            result.ShouldBeTrue(buildOutput.GetConsoleLog());
            packagePath.ShouldNotBeEmpty();
        }

        // NOTE: binlog does not look correct and seems to be missing actual content for PkgPackageA 
    }
}

Restore project information is not present in the binlog

If you run a tests with binlog and do
TryBuild(restore:true,...) then the actual Restore information (Target execution and project files) is not present in the binlog file (only the Default build information is present).

If you do seperate Restore/Build Target it does include the correct Restore Target information, e.g. with

TryBuild("Restore",... )
TryBuild("Build",...)

We noticed this because we have a project that only runs in the Restore phase of the build, but did not end up in the binlog file when we use restore:true.

Question: generate solutions?

Any ideas on generation a solution file with a fluent api similar to how this generates project files?

Best practices for preferring local .nupkg

Hi there!

This isn't a bug report, instead I'm asking about the "best" way to create a project that references a locally built NuGet package. My ultimate goal is to allow developers on my team to be able to create 'test projects' that consume and exercise locally built NuGet packages (built via <GeneratePackageOnBuild>) when those projects contain .props / .targets files.

Here's a sample setup:

Uri[] packageFeeds = new[]
{
    "https://api.nuget.org/v3/index.json",
    packageFolder,
}.Select(path => new Uri(path!)).ToArray();

using (PackageRepository repo = PackageRepository.Create(temp.FullName, packageFeeds))
{
    var project = ProjectCreator.Templates.SdkCsproj()
        .ItemPackageReference("MyCustomPackage, version: "*")
        .ItemPackageReference("Newtonsoft.Json", version: "*")
        .Save(Path.Combine("path/to/temp", "Sample.csproj"));

    project.TryBuild(restore: true, target: "Build", out bool result, out BuildOutput buildOutput, out IDictionary<string, TargetResult>? targetOutputs);

    result.Should().BeTrue(); // Additional validation omitted
}

In this example, MyCustomPackage should come from the local packageFolder, however it may also be available on NuGet (for instance, when testing a new version of the package).

As written above, NuGet will restore the latest version of my package, regardless of source. Thus, if the user doesn't increment the package version before running this test they may get the public version instead of the private version.

One way to solve that problem is to replace the version wildcard with a specific version. That reduces the chance of getting the wrong package version, however:

It still doesn't eliminate it if there's a version collision between sources
It now requires inspecting the local packages to extract the version, which is usually either fragile (like parsing from file name), or causes people to pull in NuGet.Packages, which is likely to cause version mismatches like #170

Two ways I've thought of to address the problem are:

Add Package Source Mapping support to the PackageRepository. Then I could map MyCustomPackage to the local feed and * to the NuGet feed and ensure I get the behavior I want
Extend PackageRepository to have a .FromNupkg() (or similar) like .FileCustom() that unpacks a NuGet package to a directory, though I don't know if there's additional work to get targets included and other machinery that NuGet does during a restore

Let me know if this makes sense / if you have any questions. I'm also open to the advice of "you're using the wrong tool for the job" :).

Creating new ProjectCreator throws FileNotFoundException

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:

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

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

Tests timing out with the MSBUILDNOINPROCNODE change

I don't know exactly whats causing this but i've narrowed a test timeout / long CI time issue down to release 6.3.1 where this change went in. the dependabot pr branch didnt even finish and i thought it was something related to github actions so i just yoinked the change in with admin powers 😂
Today i ran my test suite locally and noticed that outside of Visual Studio my tests were just skipping themselves:

You can see the change in finish time in the github action when the change went in:
https://github.com/MeikTranel/NXPorts/actions?query=branch%3Amaster

I tested locally and the the upgrade to 6.2.4 and 6.3.0 was fine - only after upgrading to 6.3.1 the degradation started reappearing.

I also noticed that once i SIGINT'd the dotnet test process tons of msbuild nodes still locked my test binaries (God bless LockHunter 😂)

Collecting build output breaks user specified loggers

When building a project with loggers and collecting a BuildOutput object, the user specified loggers are ignored.

failure: MSB4223: A node of the required type InProc could not be created.

I have a test project that I am upgrading from MSBuildProjectCreation 3.0.5 to 6.2.4
This test project fails with "error MSB4223: A node of the required type InProc could not be created."

The scenario that this test tries to cover should be similar to a solution building multiple projects.
(in our case we are actually testing the building of 2 solutions in the right order based on dependencies defined in our custom MSBuild targets files)

I saw in the changelogs that there was a recent change with outproc build #111

This includes a hardcoded setting with MaxNodeCount = 1, I am wondering if that could be the explanation of our specific failure since we have on project file that is using the MSBuild task to build multiple other "projects"?