Easy Acquisition of .NET Framework Targeting Pack

[terrajobst]

We believe this is the final plan. Modulo more feedback, we'll be accepting this.

/cc @dsplaisted @marek-safar

[tannergooding]

I understand this is a non-goal (and why), but what would prevent this from "just working"? #ByDesign

[dsplaisted]

I think we should allow this to work if it's not difficult. It should be possible with the proof of concept packages I created. #ByDesign

[jaredpar]

We were able to do this with our NuGet packages in old-school project files. Don't see this as too hard. There is really just one MSBuild variable you have to toggle. #ByDesign

[terrajobst]

I wrote this before NuGet was doubling down on deprecating and replacing packages.config. I think fully supporting this in non-SDK style projects is much more viable now. #ByDesign

[NickCraver]

I'd really like to see this supported in old style .csproj projects that are using <PackageReference>...that's where many of us in ASP.NET will still be for a while yet.

[dsplaisted]

@NickCraver The current plan is that it will be supported, you'll just have to explicitly add the PackageReference

[davkean]

Oh that changes things a bunch and adds other issues.

[tannergooding]

Was any thought given to just release the net462 reference assemblies in a Microsoft.NETFramework.ReferenceAssemblies, v4.6.2 package, and to have a separate Microsoft.NETFramework.ReferenceAssemblies.All metapackage?
#ByDesign

[tannergooding]

I think this would result in (overall) fewer names, easier to find/reason about, etc #ByDesign

[nguerrera]

There have been (rare) occasions where reference assemblies had a bug that was serviced. I think that would be blocked by TFM version == package version. #ByDesign

[dsplaisted]

Yes, using the target framework version as the package version would prevent us from servicing the package if we needed to.

Also, we wouldn't want someone to manually reference the Microsoft.NETFramework.ReferenceAssemblies package, and end up with the wrong version of the package for the version of the framework they're targeting (which could happen if they retarget their project, or update to a newer package version via the NuGet UI, for example). #ByDesign

[jskeet]

Yes, each package feels like it's a separate "product" to me. The package targeting .NET 4.5.1 can't be used if you're trying to target .NET 4.5, for example - it's not just "a patched version of the same thing". It's a package you'd use for a different purpose.

So +1 to "start at 1.0.0". #ByDesign

[tannergooding]

The same could be said for .NETStandard Library and any future servicing fixes that come out for it...

I would assume that whatever plan is required there would also apply here.

I don't think that these are separate products at all, they are simply the reference assemblies for different versions of the .NET Framework #ByDesign

[nguerrera]

Netstandard.Library package version is not 1:1 with .NETStandard TFM version either. #ByDesign

[terrajobst]

Netstandard.Library package version is not 1:1 with .NETStandard TFM version either.

Yep, and the fact that we tried to "look" close to the TFM version has caused more problem than it solved. 1.0.0 is the way to go. #ByDesign

[eerhardt]

@dsplaisted - when we do this work, make sure the <PreserveCompilationContext> and ASP.NET Razor compilation still works correctly even without the targeting pack installed in %ProgramFiles%. There is some code today that looks for the targeting pack installation location in both the SDK and in Microsoft.Extensions.DependencyModel.

https://github.com/dotnet/sdk/blob/c1a276fb456606e2b19d4646f8239d2546790d42/src/Tasks/Microsoft.NET.Build.Tasks/FrameworkReferenceResolver.cs#L14
and
https://github.com/dotnet/core-setup/blob/3c802455b2d8d01470e064e7557bec6faccf496e/src/managed/Microsoft.Extensions.DependencyModel/Resolution/ReferenceAssemblyPathResolver.cs#L103 #Resolved

[eerhardt]

@dsplaisted - when we do this work, make sure the <PreserveCompilationContext> and ASP.NET Razor compilation still works correctly even without the targeting pack installed in %ProgramFiles%. There is some code today that looks for the targeting pack installation location in both the SDK and in Microsoft.Extensions.DependencyModel.

https://github.com/dotnet/sdk/blob/c1a276fb456606e2b19d4646f8239d2546790d42/src/Tasks/Microsoft.NET.Build.Tasks/FrameworkReferenceResolver.cs#L14
and
https://github.com/dotnet/core-setup/blob/3c802455b2d8d01470e064e7557bec6faccf496e/src/managed/Microsoft.Extensions.DependencyModel/Resolution/ReferenceAssemblyPathResolver.cs#L103 #Resolved

[jnm2]

😭 Libraries like NUnit could really use this. This is what is preventing the dotnet CLI from being able to build net40 and earlier. What's the cost of two or three more targeting packs? #ByDesign

[ghost]

Please provide all PCL and .NET Framework 2+ packages. They are already shipped out and not going to get any updates anyway, so hopefully no additional cost than just package once and push to nuget.. #ByDesign

[dsplaisted]

I think we should provide the .NET 4.0 targeting pack, and possibly other 4.0.x versions in reference assemblies. We already have targeting packs for these, so I don't think there are any obstacles to this.

For .NET 3.5.1 and lower, we didn't ship targeting packs in the same way. PCL reference assemblies are also a bit different. I would propose that initially we not support them, in order to get basic .NET Framework support out more quickly. #ByDesign

[jnm2]

@dsplaisted If net35 is merely deprioritized without closing the door on it, I can cheer up. 😃 (net20 would also make some folks happier, and by extension, me.) #ByDesign

[tannergooding]

This would also fix cases, like in Roslyn, where custom packages are created #ByDesign

[terrajobst]

I have talked to @jaredpar and it seems you guys don't need pre-.NET Framework 4.5 support. Is that not true? #ByDesign

[terrajobst]

@jnm2

What's the cost of two or three more targeting packs?

It's mostly consistency in our offerings; we don't want to breath more life into frameworks that are that old. That being said, we can always ship more targeting packs in the future if that becomes necessary. Based on adoption I don't see enough evidence that this is necessary though. #ByDesign

[terrajobst]

@dsplaisted

I think we should provide the .NET 4.0 targeting pack, and possibly other 4.0.x versions in reference assemblies. We already have targeting packs for these, so I don't think there are any obstacles to this.

That's a fair point. How about this: I leave the wording in the spec as-is; if we can easily build the 4.0 set, great, we'll ship it. If not or we run out of time, we don't. Usage wise, I don't see compelling reasons to spend a great deal of time on 4.0. And 4.5 just makes sense from a .NET Standard support matrix stand point. #ByDesign

[jnm2]

@terrajobst

It's mostly consistency in our offerings; we don't want to breath more life into frameworks that are that old.

So long as VSTest ships a net35-compiled test execution engine, that puts pressure on NUnit to ship a net35 assembly so that we aren't the ones preventing people from testing on CLR v2 if they need to. A net35 targeting pack would be preferable to what we're doing now, using Mono's edition of net35. #WontFix

[terrajobst]

Not sure I buy that: xUnit only supports .NET Standard 1.1. And the number of 3.5 installs is quite low. I think I'm fine with 4.0 but I'm definitely opposed to go lower, especially because the whole 2.0, 3.0, 3.5 TPs are much more convoluted. #Resolved

[weshaggard]

I think we may need to set FrameworkPathOverride as well to avoid other weird issues like the explicit mscorlib reference. #Resolved

[dsplaisted]

I think we should allow this to work if it's not difficult. It should be possible with the proof of concept packages I created. #ByDesign

[dsplaisted]

I think we should provide the .NET 4.0 targeting pack, and possibly other 4.0.x versions in reference assemblies. We already have targeting packs for these, so I don't think there are any obstacles to this.

For .NET 3.5.1 and lower, we didn't ship targeting packs in the same way. PCL reference assemblies are also a bit different. I would propose that initially we not support them, in order to get basic .NET Framework support out more quickly. #ByDesign

[dsplaisted]

Yes, using the target framework version as the package version would prevent us from servicing the package if we needed to.

Also, we wouldn't want someone to manually reference the Microsoft.NETFramework.ReferenceAssemblies package, and end up with the wrong version of the package for the version of the framework they're targeting (which could happen if they retarget their project, or update to a newer package version via the NuGet UI, for example). #ByDesign

[dasMulli]

Ideally, the metapackage would also have a targets file to check for the maximum supported version and report an error if a net* version is targeted greater than the currently supported version or else the consuming project might end up with reference assemblies for the lower version if resolution falls back to the latest dependency group of the metapackage. #Resolved

[terrajobst]

Hey @dsplaisted, is this needed or is this handled by the way the targets work? #Resolved

[dsplaisted]

In my proof of concept, this is basically handled handled by conditioning setting the reference assembly path on the exact target framework version. The package for 4.7.1, for example, has the following in the .targets file:

  <PropertyGroup Condition=" ('$(UseReferenceAssembliesFromPackage)' == 'true') And ('$(TargetFrameworkIdentifier)' == '.NETFramework') And ('$(TargetFrameworkVersion)' == 'v4.7.1') ">
    <TargetFrameworkRootPath>$(MSBuildThisFileDirectory)</TargetFrameworkRootPath>
    <_NeedToRemoveExplicitReference>true</_NeedToRemoveExplicitReference>
  </PropertyGroup>

So you wouldn't get the wrong reference assemblies, you'd just get the same error you get today if reference assemblies aren't available. #Resolved

[nguerrera]

We should improve on the error that you get today. It warns, "hey, you'll get refs from the GAC, which is totally wrong and stupid, but YOLO the build might succeed." This is especially silly in SDK projects where the GAC is excluded from search paths. #Resolved

[nguerrera]

(and where there often is no GAC (.NET Core msbuild)) #Resolved

[jskeet]

Yes, each package feels like it's a separate "product" to me. The package targeting .NET 4.5.1 can't be used if you're trying to target .NET 4.5, for example - it's not just "a patched version of the same thing". It's a package you'd use for a different purpose.

So +1 to "start at 1.0.0". #ByDesign

[jaredpar]

We were able to do this with our NuGet packages in old-school project files. Don't see this as too hard. There is really just one MSBuild variable you have to toggle. #ByDesign

[terrajobst]

@eerhardt

when we do this work, make sure the <PreserveCompilationContext> and ASP.NET Razor compilation still works correctly even without the targeting pack installed in %ProgramFiles%. There is some code today that looks for the targeting pack installation location in both the SDK and in Microsoft.Extensions.DependencyModel.

That's a great point. I'll call it out in the requirements.

[terrajobst]

@eerhardt

when we do this work, make sure the <PreserveCompilationContext> and ASP.NET Razor compilation still works correctly even without the targeting pack installed in %ProgramFiles%. There is some code today that looks for the targeting pack installation location in both the SDK and in Microsoft.Extensions.DependencyModel.

That's a great point. I'll call it out in the requirements.

[jnm2]

@terrajobst What does the added #ByDesign on most of our comments mean?

[jnm2]

@terrajobst What does the added #ByDesign on most of our comments mean?

[dsplaisted]

I've filed dotnet/sdk#2054 to track fixing PreserveCompilationContext. I don't think we should block the rest of the work on this issue though. #Resolved

[eerhardt]

I'm not sure what you mean by "block the rest of the work", but we can't make using the NuGet targeting pack the default in SDK projects without this issue being addressed. Or else you will break every ASP.NET MVC/Razor Page app running on the desktop .NET Framework. #Resolved

[nguerrera]

As I understand it, the idea for the first turn of the crank is that you can build without the program files TP but razor will still need it to be there to run. It needn't break anything that already works. You can build against nuget and dynamically compile against the same content in program files at runtime.

Step 2 would be to write out the actual nuget location that build used, and plumb that through for runtime compilation consumption. #Resolved

[dsplaisted]

The current plan is to only reference the NuGet packages if the targeting pack isn't found in program files. So if you have the reference assemblies installed, everything would continue to work.

I think everything would still work even if we did use the reference assembly packages for compilation as long as you have the reference assemblies installed. Different parts of the build would be getting the reference assemblies from different locations, but they should be the same files. #Resolved

[nguerrera]

(I tried to say the same thing, but Daniel worded it better. :)) #Resolved

[eerhardt]

Sounds good. I just wanted to call out that this area is a bug factory, and often gets overlooked. #Resolved

[davkean]

I think you are missing two things from this doc:

Visual Studio:

• Global DTAR (IVsFrameworkMultiTargeting) and project DTAR (IVsDesignTimeAssemblyResolution) will fail to return the correct results, breaking any feature that calls into them, Application, WinForms and WPF designers are examples of this. The TFM prompt is another example when the TFM isn't installed.
• Reference Manager dialog, what does it show I don't think it uses project context to locate the framework? Does it say that the entire framework is already referenced?
• How do you rationalize between explicitly referencing a dll when using targeting pack , and presumably auto-referencing via the package? How do you switch "between" these modes if this is automatic - they both seem very different.
• How do you warn/prevent legacy projects from using this package? This package is going to cause a few problems with it (if you mix explicit refs with auto-refs, they become unresolved, which cause UI and performance issues) and I'd rather see this avoided vs bugs being filed against VS.
• ClickOnce - ClickOnce has different behavior for framework assemblies vs user reference assemblies, I don't think it uses project context
• Windows Installer - Windows installer extensions uses the RedistList to determine whether a redist gets automatically included in the bootstrapper or whether the binary gets included. I don't think it uses project context

Performance:

• There is a ton-load of performance shortcuts that occurs when using the targeting pack, for example, we read RedistList.xml instead of opening each individual dll. I'd rather see this addressed before we ship this feature, rather than after like what occured with .NET Core. How we make sure we don't start regressing build performance when this is opt'd in?
• There's a performance shortcut for locating framework directory in .NETFramework.props

[davkean]

I think you are missing two things from this doc:

Visual Studio:

• Global DTAR (IVsFrameworkMultiTargeting) and project DTAR (IVsDesignTimeAssemblyResolution) will fail to return the correct results, breaking any feature that calls into them, Application, WinForms and WPF designers are examples of this. The TFM prompt is another example when the TFM isn't installed.
• Reference Manager dialog, what does it show I don't think it uses project context to locate the framework? Does it say that the entire framework is already referenced?
• How do you rationalize between explicitly referencing a dll when using targeting pack , and presumably auto-referencing via the package? How do you switch "between" these modes if this is automatic - they both seem very different.
• How do you warn/prevent legacy projects from using this package? This package is going to cause a few problems with it (if you mix explicit refs with auto-refs, they become unresolved, which cause UI and performance issues) and I'd rather see this avoided vs bugs being filed against VS.
• ClickOnce - ClickOnce has different behavior for framework assemblies vs user reference assemblies, I don't think it uses project context
• Windows Installer - Windows installer extensions uses the RedistList to determine whether a redist gets automatically included in the bootstrapper or whether the binary gets included. I don't think it uses project context

Performance:

• There is a ton-load of performance shortcuts that occurs when using the targeting pack, for example, we read RedistList.xml instead of opening each individual dll. I'd rather see this addressed before we ship this feature, rather than after like what occured with .NET Core. How we make sure we don't start regressing build performance when this is opt'd in?
• There's a performance shortcut for locating framework directory in .NETFramework.props

[davkean]

Oh seems like I'm missing context not called out in the doc, but you mentioned on twitter - you are just changing where TFM folder is found, and not using NuGet mechanisms to auto-reference the dlls? I still have some different concerns, but want to understand the implementation before I add them.

[davkean]

Oh seems like I'm missing context not called out in the doc, but you mentioned on twitter - you are just changing where TFM folder is found, and not using NuGet mechanisms to auto-reference the dlls? I still have some different concerns, but want to understand the implementation before I add them.

[onovotny]

Does this cover all .NET Framework targets? I.e., what about WPF and WCF? Does this mean that WPF can be built on a Mac via Mono? This spec seems to imply that.

[onovotny]

Does this cover all .NET Framework targets? I.e., what about WPF and WCF? Does this mean that WPF can be built on a Mac via Mono? This spec seems to imply that.

[niemyjski]

Amazing! Just so I understand this correctly as stated in the goals, I should be able to pull in a targeting pack nuget package for full framework and build cross platform, kinda like how VS Extensibility packages are on nuget but I don't have to have old sdks? From reading this sounds like I can finally build our full framework packages cross platform like a WPF library with a WPF Pack (It won't run xplat but I could build it). But the text is a bit confusing because the goals state xplat but then you have

It's not cross-platform friendly. The .NET Framework Developer Packs are
only available for Windows which makes the targeting packs indirectly Windows-
only too.

[niemyjski]

Amazing! Just so I understand this correctly as stated in the goals, I should be able to pull in a targeting pack nuget package for full framework and build cross platform, kinda like how VS Extensibility packages are on nuget but I don't have to have old sdks? From reading this sounds like I can finally build our full framework packages cross platform like a WPF library with a WPF Pack (It won't run xplat but I could build it). But the text is a bit confusing because the goals state xplat but then you have

It's not cross-platform friendly. The .NET Framework Developer Packs are
only available for Windows which makes the targeting packs indirectly Windows-
only too.

[akoeplinger]

@onovotny @niemyjski if you only consume APIs from the WPF assemblies/namespaces in a library then I'd expect that to work with this spec, but you won't automatically get e.g. the XAML markup compiler and other tools.

[akoeplinger]

@onovotny @niemyjski if you only consume APIs from the WPF assemblies/namespaces in a library then I'd expect that to work with this spec, but you won't automatically get e.g. the XAML markup compiler and other tools.

[onovotny]

@akoeplinger I assumed as much, but I think that needs to be explicitly called out or potentially detected and with an error generated at build time.

[onovotny]

@akoeplinger I assumed as much, but I think that needs to be explicitly called out or potentially detected and with an error generated at build time.

[dsplaisted]

@davkean The reference assembly packages have a targets file that looks like this:

<!--
***********************************************************************************************
Microsoft.NETFramework.ReferenceAssemblies.net462.targets
WARNING:  DO NOT MODIFY this file unless you are knowledgeable about MSBuild and have
          created a backup copy.  Incorrect changes to this file will make it
          impossible to load or build your projects from the command-line or the IDE.
Copyright (c) .NET Foundation. All rights reserved.
***********************************************************************************************
-->
<Project>
  <PropertyGroup Condition=" ('$(TargetFrameworkIdentifier)' == '.NETFramework') And ('$(TargetFrameworkVersion)' == 'v4.6.2') ">
    <TargetFrameworkRootPath>$(MSBuildThisFileDirectory)</TargetFrameworkRootPath>
    
    <!-- FrameworkPathOverride is typically not set to the correct value, and the common targets include mscorlib from FrameworkPathOverride.
         So disable FrameworkPathOverride, set NoStdLib to true, and explicitly reference mscorlib here. -->
    <EnableFrameworkPathOverride>false</EnableFrameworkPathOverride>
    <NoStdLib>true</NoStdLib>
  </PropertyGroup>
  
  <ItemGroup Condition=" ('$(TargetFrameworkIdentifier)' == '.NETFramework') And ('$(TargetFrameworkVersion)' == 'v4.6.2') ">
    <Reference Include="mscorlib" />
  </ItemGroup>

</Project>

And then the folder structure from the installed targeting pack is replicated:

The PoC code to produce these packages is here: https://github.com/dsplaisted/ReferenceAssemblyPackages

[dsplaisted]

@davkean The reference assembly packages have a targets file that looks like this:

<!--
***********************************************************************************************
Microsoft.NETFramework.ReferenceAssemblies.net462.targets
WARNING:  DO NOT MODIFY this file unless you are knowledgeable about MSBuild and have
          created a backup copy.  Incorrect changes to this file will make it
          impossible to load or build your projects from the command-line or the IDE.
Copyright (c) .NET Foundation. All rights reserved.
***********************************************************************************************
-->
<Project>
  <PropertyGroup Condition=" ('$(TargetFrameworkIdentifier)' == '.NETFramework') And ('$(TargetFrameworkVersion)' == 'v4.6.2') ">
    <TargetFrameworkRootPath>$(MSBuildThisFileDirectory)</TargetFrameworkRootPath>
    
    <!-- FrameworkPathOverride is typically not set to the correct value, and the common targets include mscorlib from FrameworkPathOverride.
         So disable FrameworkPathOverride, set NoStdLib to true, and explicitly reference mscorlib here. -->
    <EnableFrameworkPathOverride>false</EnableFrameworkPathOverride>
    <NoStdLib>true</NoStdLib>
  </PropertyGroup>
  
  <ItemGroup Condition=" ('$(TargetFrameworkIdentifier)' == '.NETFramework') And ('$(TargetFrameworkVersion)' == 'v4.6.2') ">
    <Reference Include="mscorlib" />
  </ItemGroup>

</Project>

And then the folder structure from the installed targeting pack is replicated:

The PoC code to produce these packages is here: https://github.com/dsplaisted/ReferenceAssemblyPackages

[davkean]

I crossed out my concerns that aren't relevant based on the design. The biggest one is not everything in VS uses project context to find reference assemblies.

[davkean]

I crossed out my concerns that aren't relevant based on the design. The biggest one is not everything in VS uses project context to find reference assemblies.

[terrajobst]

@davkean thanks for the feedback! I'll work @dsplaisted to make sure we incorporate them into the doc and come up with a design that will address those.

[terrajobst]

@davkean thanks for the feedback! I'll work @dsplaisted to make sure we incorporate them into the doc and come up with a design that will address those.

[terrajobst]

@onovotny

Does this cover all .NET Framework targets? I.e., what about WPF and WCF? Does this mean that WPF can be built on a Mac via Mono? This spec seems to imply that.

You'll be able to write code against any APIs in the .NET Framework, including WPF and WCF. However, this work will not do anything to MSBuild to generate additional artifacts on, say, a Mac. This will likely mean you won't be able to generate .baml files.

I'll add this section to the non-goals.

[terrajobst]

@onovotny

Does this cover all .NET Framework targets? I.e., what about WPF and WCF? Does this mean that WPF can be built on a Mac via Mono? This spec seems to imply that.

You'll be able to write code against any APIs in the .NET Framework, including WPF and WCF. However, this work will not do anything to MSBuild to generate additional artifacts on, say, a Mac. This will likely mean you won't be able to generate .baml files.

I'll add this section to the non-goals.

[terrajobst]

@niemyjski

Amazing! Just so I understand this correctly as stated in the goals, I should be able to pull in a targeting pack nuget package for full framework and build cross platform, kinda like how VS Extensibility packages are on nuget but I don't have to have old sdks? From reading this sounds like I can finally build our full framework packages cross platform like a WPF library with a WPF Pack (It won't run xplat but I could build it). But the text is a bit confusing because the goals state xplat but then you have

It's not cross-platform friendly. The .NET Framework Developer Packs are
only available for Windows which makes the targeting packs indirectly Windows-
only too.

The text you quoted is from the introduction that lists the shortcomings of the current targeting packs. Yes, you'll be able acquire the targeting packs on non-Windows machines as they are simple NuGet packages. This will unblock regular class libraries that just want to invoke APIs only present in the .NET Framework/Mono but are missing from .NET Core/.NET Standard. However, as I said above we aren't planning to extending the cross-platform MSBuild feature set as part of this work item. So you'll not be able to take your .NET Framework WPF application and have that build on a Linux machine.

[terrajobst]

@niemyjski

Amazing! Just so I understand this correctly as stated in the goals, I should be able to pull in a targeting pack nuget package for full framework and build cross platform, kinda like how VS Extensibility packages are on nuget but I don't have to have old sdks? From reading this sounds like I can finally build our full framework packages cross platform like a WPF library with a WPF Pack (It won't run xplat but I could build it). But the text is a bit confusing because the goals state xplat but then you have

It's not cross-platform friendly. The .NET Framework Developer Packs are
only available for Windows which makes the targeting packs indirectly Windows-
only too.

The text you quoted is from the introduction that lists the shortcomings of the current targeting packs. Yes, you'll be able acquire the targeting packs on non-Windows machines as they are simple NuGet packages. This will unblock regular class libraries that just want to invoke APIs only present in the .NET Framework/Mono but are missing from .NET Core/.NET Standard. However, as I said above we aren't planning to extending the cross-platform MSBuild feature set as part of this work item. So you'll not be able to take your .NET Framework WPF application and have that build on a Linux machine.

[dsplaisted]

There's a performance shortcut for locating framework directory in .NETFramework.props

@davkean I see code that's special-cased for .NET Framework 4.0. Is that what you're referring to? It looks like there are other special cases for versions prior to 4.0 in Microsoft.NETFramework.CurrentVersion.targets. But I don't see any shortcuts for any version of .NET after 4.0.

[dsplaisted]

There's a performance shortcut for locating framework directory in .NETFramework.props

@davkean I see code that's special-cased for .NET Framework 4.0. Is that what you're referring to? It looks like there are other special cases for versions prior to 4.0 in Microsoft.NETFramework.CurrentVersion.targets. But I don't see any shortcuts for any version of .NET after 4.0.

[Nirmal4G]

@terrajobst @dsplaisted .NETFramework exists only on windows, It makes sense to build only on Windows when the project includes Xaml and other Windows-only stuff. But at least can you not make the targeting packs have tools that build good on a CI server with only MSBuild tools installed. That's kinda the goal for Build Tools edition, right?

It doesn't need to be cross-platform but the package can be Windows-only!

This goes like this, in the CI-server:

1. Clone any supported .NET OSS/Private project.
2. On a clean Windows machine, install only MSBuild Tools.
3. Run MSBuild /Restore MySolution.sln
4. The solution builds successfully by getting relevant targeting packs and any additional .NETFramework only tools and stuff from the NuGet!

Note.: The only thing we have to install along with Build Tools would be necessary .NETFramework Runtime (for running the tools we've got from NuGet packages)

[Nirmal4G]

@terrajobst @dsplaisted .NETFramework exists only on windows, It makes sense to build only on Windows when the project includes Xaml and other Windows-only stuff. But at least can you not make the targeting packs have tools that build good on a CI server with only MSBuild tools installed. That's kinda the goal for Build Tools edition, right?

It doesn't need to be cross-platform but the package can be Windows-only!

This goes like this, in the CI-server:

1. Clone any supported .NET OSS/Private project.
2. On a clean Windows machine, install only MSBuild Tools.
3. Run MSBuild /Restore MySolution.sln
4. The solution builds successfully by getting relevant targeting packs and any additional .NETFramework only tools and stuff from the NuGet!

Note.: The only thing we have to install along with Build Tools would be necessary .NETFramework Runtime (for running the tools we've got from NuGet packages)

[ghost]

@Nirmal4G, targeting packs will work with Windows (.NET Framework) as well as Unix (Mono).

[ghost]

@Nirmal4G, targeting packs will work with Windows (.NET Framework) as well as Unix (Mono).

[omajid]

Is there any reason not to use an open source license, like MIT, for these reference assemblies?

[AArnott]

What about PCL profiles? Is that a goal or non-goal? Several popular nuget packages still target PCLs because quite a few customers still use VS2015. Personally, I own several packages that build from .NET SDK projects and multi-target .netstandard*, net4*, and portable-*, and testing on mac+linux is important to us.

[ghost]

.NET 2, 3, 3.5 and PCL profiles would be great! Partial support will only result in partial reliance, which is not good enough in many popular packages like Newtonsoft.JSON etc.

[dasMulli]

I don't think that there are reference assemblies / targeting packs for <= 3.5
MSBuild even requires to run a version of MSBuildTaskHost.exe on the system install of the CLR 2 (.NET 2, 3, 3.5) in order to build .NET 3.5 projects.