New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Easy Acquisition of .NET Framework Targeting Pack #33

Open
wants to merge 1 commit into
base: master
from

Conversation

@terrajobst
Member

terrajobst commented Mar 13, 2018

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

/cc @dsplaisted @marek-safar

@terrajobst terrajobst self-assigned this Mar 13, 2018

### Non-Goals
* Supporting NuGet-based acquisition of the .NET Framework runtime
* Supporting NuGet-based acquisition from non-SDK-style projects

This comment has been minimized.

@tannergooding

tannergooding Mar 13, 2018

Member

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

@tannergooding

tannergooding Mar 13, 2018

Member

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

This comment has been minimized.

@dsplaisted

dsplaisted Mar 14, 2018

Member

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

dsplaisted Mar 14, 2018

Member

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

This comment has been minimized.

@jaredpar

jaredpar Mar 14, 2018

Member

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

@jaredpar

jaredpar Mar 14, 2018

Member

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

This comment has been minimized.

@terrajobst

terrajobst Mar 14, 2018

Member

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

@terrajobst

terrajobst Mar 14, 2018

Member

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

This comment has been minimized.

@NickCraver

NickCraver Mar 30, 2018

Member

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.

@NickCraver

NickCraver Mar 30, 2018

Member

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.

This comment has been minimized.

@dsplaisted

dsplaisted Mar 30, 2018

Member

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

@dsplaisted

dsplaisted Mar 30, 2018

Member

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

This comment has been minimized.

@davkean

davkean Mar 30, 2018

Member

Oh that changes things a bunch and adds other issues.

@davkean

davkean Mar 30, 2018

Member

Oh that changes things a bunch and adds other issues.

intellisense files in the `build\.NETFramework\v4.6.2` folder, as well as have
the `Facades`, `PermissionSets`, and `RedistList` folders with corresponding
files under that folder.
* The version number of each package should start at 1.0.0. When a new version

This comment has been minimized.

@tannergooding

tannergooding Mar 13, 2018

Member

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

tannergooding Mar 13, 2018

Member

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

This comment has been minimized.

@tannergooding

tannergooding Mar 13, 2018

Member

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

@tannergooding

tannergooding Mar 13, 2018

Member

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

This comment has been minimized.

@nguerrera

nguerrera Mar 13, 2018

Member

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

@nguerrera

nguerrera Mar 13, 2018

Member

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

This comment has been minimized.

@dsplaisted

dsplaisted Mar 14, 2018

Member

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

@dsplaisted

dsplaisted Mar 14, 2018

Member

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

This comment has been minimized.

@jskeet

jskeet Mar 14, 2018

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

@jskeet

jskeet Mar 14, 2018

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

This comment has been minimized.

@tannergooding

tannergooding Mar 14, 2018

Member

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

@tannergooding

tannergooding Mar 14, 2018

Member

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

This comment has been minimized.

@nguerrera

nguerrera Mar 14, 2018

Member

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

@nguerrera

nguerrera Mar 14, 2018

Member

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

This comment has been minimized.

@terrajobst

terrajobst Mar 14, 2018

Member

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

@terrajobst

terrajobst Mar 14, 2018

Member

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

This comment has been minimized.

Show comment
Hide comment
@eerhardt

eerhardt Mar 13, 2018

Member

@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

Member

eerhardt commented Mar 13, 2018

@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

* Supporting NuGet-based acquisition of the .NET Framework runtime
* Supporting NuGet-based acquisition from non-SDK-style projects
* Support pre-.NET Framework 4.5 targeting packs

This comment has been minimized.

@jnm2

jnm2 Mar 13, 2018

Contributor

😭 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

@jnm2

jnm2 Mar 13, 2018

Contributor

😭 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

This comment has been minimized.

@ghost

ghost Mar 13, 2018

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

@ghost

ghost Mar 13, 2018

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

This comment has been minimized.

@dsplaisted

dsplaisted Mar 14, 2018

Member

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

dsplaisted Mar 14, 2018

Member

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

This comment has been minimized.

@jnm2

jnm2 Mar 14, 2018

Contributor

@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

@jnm2

jnm2 Mar 14, 2018

Contributor

@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

This comment has been minimized.

@tannergooding

tannergooding Mar 14, 2018

Member

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

@tannergooding

tannergooding Mar 14, 2018

Member

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

This comment has been minimized.

@terrajobst

terrajobst Mar 14, 2018

Member

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

terrajobst Mar 14, 2018

Member

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

This comment has been minimized.

@terrajobst

terrajobst Mar 14, 2018

Member

@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

terrajobst Mar 14, 2018

Member

@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

This comment has been minimized.

@terrajobst

terrajobst Mar 14, 2018

Member

@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

@terrajobst

terrajobst Mar 14, 2018

Member

@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

This comment has been minimized.

@jnm2

jnm2 Mar 15, 2018

Contributor

@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

@jnm2

jnm2 Mar 15, 2018

Contributor

@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

This comment has been minimized.

@terrajobst

terrajobst Mar 15, 2018

Member

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

@terrajobst

terrajobst Mar 15, 2018

Member

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

- For the version-specific packages:
`Microsoft.NETFramework.ReferencesAssemblies.net462` (where net462 is
replaced with the corresponding NuGet short framework Identifier)
* The NuGet packages will include a `.targets` file that sets the

This comment has been minimized.

@weshaggard

weshaggard Mar 13, 2018

Member

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

@weshaggard

weshaggard Mar 13, 2018

Member

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

Show outdated Hide outdated accepted/targeting-packs/targeting-packs.md Outdated
### Non-Goals
* Supporting NuGet-based acquisition of the .NET Framework runtime
* Supporting NuGet-based acquisition from non-SDK-style projects

This comment has been minimized.

@dsplaisted

dsplaisted Mar 14, 2018

Member

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

dsplaisted Mar 14, 2018

Member

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

* Supporting NuGet-based acquisition of the .NET Framework runtime
* Supporting NuGet-based acquisition from non-SDK-style projects
* Support pre-.NET Framework 4.5 targeting packs

This comment has been minimized.

@dsplaisted

dsplaisted Mar 14, 2018

Member

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

dsplaisted Mar 14, 2018

Member

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

Show outdated Hide outdated accepted/targeting-packs/targeting-packs.md Outdated
Show outdated Hide outdated accepted/targeting-packs/targeting-packs.md Outdated
Show outdated Hide outdated accepted/targeting-packs/targeting-packs.md Outdated
Show outdated Hide outdated accepted/targeting-packs/targeting-packs.md Outdated
intellisense files in the `build\.NETFramework\v4.6.2` folder, as well as have
the `Facades`, `PermissionSets`, and `RedistList` folders with corresponding
files under that folder.
* The version number of each package should start at 1.0.0. When a new version

This comment has been minimized.

@dsplaisted

dsplaisted Mar 14, 2018

Member

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

@dsplaisted

dsplaisted Mar 14, 2018

Member

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

of the .NET Framework is released, a corresponding reference assembly package
(versioned at 1.0.0) should be released, and a new metapackage that includes
the additional dependency for the newly supported version should be released.
The new version of the metapackage should have it's minor version incremented.

This comment has been minimized.

@dasMulli

dasMulli Mar 14, 2018

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

@dasMulli

dasMulli Mar 14, 2018

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

This comment has been minimized.

@terrajobst

terrajobst Mar 15, 2018

Member

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

@terrajobst

terrajobst Mar 15, 2018

Member

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

This comment has been minimized.

@dsplaisted

dsplaisted Mar 15, 2018

Member

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

@dsplaisted

dsplaisted Mar 15, 2018

Member

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

This comment has been minimized.

@nguerrera

nguerrera Mar 15, 2018

Member

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

nguerrera Mar 15, 2018

Member

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

This comment has been minimized.

@nguerrera

nguerrera Mar 15, 2018

Member

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

@nguerrera

nguerrera Mar 15, 2018

Member

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

intellisense files in the `build\.NETFramework\v4.6.2` folder, as well as have
the `Facades`, `PermissionSets`, and `RedistList` folders with corresponding
files under that folder.
* The version number of each package should start at 1.0.0. When a new version

This comment has been minimized.

@jskeet

jskeet Mar 14, 2018

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

@jskeet

jskeet Mar 14, 2018

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

Show outdated Hide outdated accepted/targeting-packs/targeting-packs.md Outdated
Show outdated Hide outdated accepted/targeting-packs/targeting-packs.md Outdated
### Non-Goals
* Supporting NuGet-based acquisition of the .NET Framework runtime
* Supporting NuGet-based acquisition from non-SDK-style projects

This comment has been minimized.

@jaredpar

jaredpar Mar 14, 2018

Member

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

@jaredpar

jaredpar Mar 14, 2018

Member

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

This comment has been minimized.

Show comment
Hide comment
@terrajobst

terrajobst Mar 14, 2018

Member

@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.

Member

terrajobst commented Mar 14, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@jnm2

jnm2 Mar 15, 2018

Contributor

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

Contributor

jnm2 commented Mar 15, 2018

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

don't change the performance characteristic of exiting solutions but also
allows working around some issue due to build extensions by installing the
targeting pack.
* Supports `<PreserveCompilationContext>` so that ASP.NET Razor compilation

This comment has been minimized.

@dsplaisted

dsplaisted Mar 16, 2018

Member

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

@dsplaisted

dsplaisted Mar 16, 2018

Member

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

This comment has been minimized.

@eerhardt

eerhardt Mar 16, 2018

Member

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

@eerhardt

eerhardt Mar 16, 2018

Member

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

This comment has been minimized.

@nguerrera

nguerrera Mar 16, 2018

Member

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

@nguerrera

nguerrera Mar 16, 2018

Member

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

This comment has been minimized.

@dsplaisted

dsplaisted Mar 16, 2018

Member

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

@dsplaisted

dsplaisted Mar 16, 2018

Member

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

This comment has been minimized.

@nguerrera

nguerrera Mar 16, 2018

Member

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

@nguerrera

nguerrera Mar 16, 2018

Member

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

This comment has been minimized.

@eerhardt

eerhardt Mar 16, 2018

Member

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

@eerhardt

eerhardt Mar 16, 2018

Member

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

@terrajobst terrajobst changed the title from WIP: Inital draft of "Easy Acquisition of .NET Framework Targeting Pack" to Easy Acquisition of .NET Framework Targeting Pack Mar 29, 2018

@davkean

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean Mar 29, 2018

Member

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
Member

davkean commented Mar 29, 2018

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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean Mar 29, 2018

Member

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.

Member

davkean commented Mar 29, 2018

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

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Mar 29, 2018

Member

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.

Member

onovotny commented Mar 29, 2018

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

This comment has been minimized.

Show comment
Hide comment
@niemyjski

niemyjski Mar 29, 2018

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 commented Mar 29, 2018

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

This comment has been minimized.

Show comment
Hide comment
@akoeplinger

akoeplinger Mar 29, 2018

Member

@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.

Member

akoeplinger commented Mar 29, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Mar 29, 2018

Member

@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.

Member

onovotny commented Mar 29, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@dsplaisted

dsplaisted Mar 29, 2018

Member

@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:
image

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

Member

dsplaisted commented Mar 29, 2018

@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:
image

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

@davkean

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean Mar 30, 2018

Member

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.

Member

davkean commented Mar 30, 2018

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

This comment has been minimized.

Show comment
Hide comment
@terrajobst

terrajobst Mar 30, 2018

Member

@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.

Member

terrajobst commented Mar 30, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@terrajobst

terrajobst Mar 30, 2018

Member

@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.

Member

terrajobst commented Mar 30, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@terrajobst

terrajobst Mar 30, 2018

Member

@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.

Member

terrajobst commented Mar 30, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@dsplaisted

dsplaisted Mar 30, 2018

Member

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.

Member

dsplaisted commented Mar 30, 2018

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

This comment has been minimized.

Show comment
Hide comment
@Nirmal4G

Nirmal4G Apr 18, 2018

@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 commented Apr 18, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Apr 19, 2018

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

ghost commented Apr 19, 2018

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

If we need to fix an issue with the packages, we can ship new versions with
the patch version incremented, and a new metapackage with dependencies on the
patched packages.
* We need to determine what license to use for these packages.

This comment has been minimized.

@omajid

omajid May 14, 2018

Member

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

@omajid

omajid May 14, 2018

Member

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

## Requirements
### Goals

This comment has been minimized.

@AArnott

AArnott Jun 6, 2018

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.

@AArnott

AArnott Jun 6, 2018

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.

This comment has been minimized.

@ghost

ghost Jun 6, 2018

.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.

@ghost

ghost Jun 6, 2018

.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.

This comment has been minimized.

@dasMulli

dasMulli Jun 6, 2018

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.

@dasMulli

dasMulli Jun 6, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment