Skip to content
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

extern alias support for NuGet package references #4989

Closed
davkean opened this issue Apr 6, 2017 · 51 comments
Closed

extern alias support for NuGet package references #4989

davkean opened this issue Apr 6, 2017 · 51 comments

Comments

@davkean
Copy link

@davkean davkean commented Apr 6, 2017

From @fubar-coder on April 5, 2017 15:59

Currently, when a NuGet package reference is added, there is no way to set the alias from the project system for the new style csproj projects.

This feature is needed, because NuGet package references don't result in direct assembly references any more and only those can have an alias.

My proposal is to add the alias(es) to all assemblies referenced for the NuGet package, but not the indirectly referenced NuGet packages.

Copied from original issue: dotnet/project-system#1930

notes

dotnet/sdk#10947 The build tasks on (.NET Core SDK side)
dotnet/NuGet.BuildTasks#70 The build tasks for the non-SDK based PackageReference
dotnet/project-system#6011 Nomination updates on project-system side.

@davkean
Copy link
Author

@davkean davkean commented Apr 6, 2017

Great suggestion. I'll move this over to the NuGet repo, they own the syntax for PackageReference.

Loading

@andymac4182
Copy link

@andymac4182 andymac4182 commented May 3, 2017

This would be great since we are running into this issue due to https://www.nuget.org/packages/StackExchange.Redis/ and https://www.nuget.org/packages/StackExchange.Redis.StrongName/

Loading

@brianpos
Copy link

@brianpos brianpos commented May 3, 2017

We have this issue to if we want to add both of these
https://www.nuget.org/packages/Hl7.Fhir.DSTU2
https://www.nuget.org/packages/Hl7.Fhir.STU3

Loading

@wburgers
Copy link

@wburgers wburgers commented May 23, 2017

@brianpos exactly the same problem here.
We would like to run both fhir versions next to each other.

Loading

@brianpos
Copy link

@brianpos brianpos commented May 23, 2017

@wburgers i have a project using the extern alias trick https://github.com/brianpos/FhirPathTester but do have to set manually after inclusion. So can't wait for this to be fixed.

Loading

@JoseFMP
Copy link

@JoseFMP JoseFMP commented Jun 21, 2017

+1, can't wait for this. I think this is important because right now different packages implementing same namespaces.

@brianpos could you share your trick please?

Loading

@fubar-coder
Copy link

@fubar-coder fubar-coder commented Jun 21, 2017

IIRC you can configure NuGet to store the NuGet packages in an packages folder instead of using the cache in the users home folder using the NuGet.config. This allows you to manually specify project-relative assembly references (via Reference Update) which can include the alias. The problem with this approach is, that you have to update the reference whenever the package version changes. However, you can restore the packages into folders without the package version of you don't have conflicting package versions.

Loading

@JoseFMP
Copy link

@JoseFMP JoseFMP commented Jun 21, 2017

Ok, so basically referencing the .dll quasi-manually and including then the alias, right? I was also thinking about that as a work around

Loading

@davkean
Copy link
Author

@davkean davkean commented Jun 21, 2017

As a side note, a workaround is to write a target that does something like this: https://github.com/dotnet/project-system/blob/master/build/Targets/VSL.Imports.targets#L340.

Here we're setting the EmbedInteropTypes metadata, but the same could be applied to alias.

Loading

@andymac4182
Copy link

@andymac4182 andymac4182 commented Jun 21, 2017

It would be great if someone on the NuGet team could point in the right direction of the repo that requires the change. I am sure people are happy to look if they know where to look.

Loading

@davkean
Copy link
Author

@davkean davkean commented Jun 21, 2017

I think they'll need a design first, I don't see a flushed out proposal on syntax/behavior. Once we do that, we'll then need to work with the project systems (http://github.com/dotnet/project-system) and SDK (http://github.com/dotnet/project-system) to add/respect the property so that it can be passed to NuGet/show in Properties, etc, added to the <REference/> when we dynamically produce them, and then plumbed through pack (what does an aliased set of references do when we add the package as a reference in the nuspec?). Just to set expectations, this isn't a couple of lines change.

Loading

@davkean
Copy link
Author

@davkean davkean commented Jun 21, 2017

I'll help sponsor, point to the locations that need to change in SDK, ProjectSystem (NuGet team will need to jump in on the nuget side, as I don't have context), and driving this through, if a community member wants to pick up the design/changes.

Loading

@gertjvr
Copy link

@gertjvr gertjvr commented Jun 23, 2017

After some experimentation and got it to work.

Placed the below snippet into my csproj file where I had both references of StackExchange.Redis and StackExchange.Redis.StrongName nuget dependencies.

<Target Name="ChangeAliasesOfStrongNameAssemblies" BeforeTargets="FindReferenceAssembliesForReferences;ResolveReferences">
    <ItemGroup>
      <ReferencePath Condition="'%(FileName)' == 'StackExchange.Redis.StrongName'">
        <Aliases>signed</Aliases>
      </ReferencePath>
    </ItemGroup>
  </Target>

Loading

@JoseFMP
Copy link

@JoseFMP JoseFMP commented Jun 23, 2017

@gertjvr sounds great! I will give it a try over here

Loading

@ewoutkramer
Copy link

@ewoutkramer ewoutkramer commented Jun 26, 2017

if a community member wants to pick up the design/changes.

What would that entail? Sorry, I am not very familiar with the process!

Loading

@fubar-coder
Copy link

@fubar-coder fubar-coder commented Jun 26, 2017

@gertjvr Just to clarify: ChangeAliasesOfStrongNameAssemblies is just a random target name? Does it need to be called/targeted somewhere?

Loading

@gertjvr
Copy link

@gertjvr gertjvr commented Jun 26, 2017

@fubar-coder the target name is just a random name same goes for the alias signed, the snippet above was all I added to my csproj file.

<Project Sdk="Microsoft.NET.Sdk">
  
  <PropertyGroup>
    <TargetFramework>net461</TargetFramework>
  </PropertyGroup>
  
  <ItemGroup>
    <PackageReference Include="Autofac" Version="4.6.0" />
    <PackageReference Include="AutofacSerilogIntegration" Version="2.0.0" />
    <PackageReference Include="AWSSDK.DynamoDBv2" Version="3.1.5" />
    <PackageReference Include="AWSSDK.S3" Version="3.1.7.2" />
    <PackageReference Include="ConfigInjector" Version="2.2.1175" />
    <PackageReference Include="Linq2DynamoDb.DataContext" Version="2.0.0" />
    <PackageReference Include="Linq2DynamoDb.DataContext.Caching.Redis" Version="2.0.0" />
    <PackageReference Include="MassTransit" Version="3.5.7" />
    <PackageReference Include="Microsoft.AspNet.SignalR.Core" Version="2.2.2" />
    <PackageReference Include="Microsoft.AspNet.SignalR.Redis" Version="2.2.2" />
    <PackageReference Include="Microsoft.Owin" Version="3.1.0" />
    <PackageReference Include="Newtonsoft.Json" Version="10.0.3" />
    <PackageReference Include="Owin" Version="1.0.0" />
    <PackageReference Include="Serilog" Version="2.5.0" />
    <PackageReference Include="ThirdDrawer" Version="1.1.9" />
  </ItemGroup>

  <ItemGroup>
    <Reference Include="Microsoft.CSharp" />
  </ItemGroup>
  
  <Target Name="ChangeAliasesOfStrongNameAssemblies" BeforeTargets="FindReferenceAssembliesForReferences;ResolveReferences">
    <ItemGroup>
      <ReferencePath Condition="'%(FileName)' == 'StackExchange.Redis.StrongName'">
        <Aliases>signed</Aliases>
      </ReferencePath>
    </ItemGroup>
  </Target>
  
</Project>

Loading

jasonmalinowski added a commit to jasonmalinowski/roslyn that referenced this issue Sep 6, 2017
…udio

We don't need the split anymore now that we're only supporting Dev15.

Unfortunately this required the introduction of a NuGet package that
has a namespace "Workspace" to our VS project, which meant I had to
disambiguate Workspace wherever it's used in that layer. I considered
doing an extern alias instead to disambiguate, but applying that to a
ProjectReference isn't supported. That's tracked by NuGet/Home#4989.
jasonmalinowski added a commit to jasonmalinowski/roslyn that referenced this issue Sep 11, 2017
…udio

We don't need the split anymore now that we're only supporting Dev15.

Unfortunately this required the introduction of a NuGet package that
has a namespace "Workspace" to our VS project, which meant I had to
disambiguate Workspace wherever it's used in that layer. I considered
doing an extern alias instead to disambiguate, but applying that to a
ProjectReference isn't supported. That's tracked by NuGet/Home#4989.
@emgarten emgarten added this to the Backlog milestone Oct 17, 2017
@emgarten
Copy link
Member

@emgarten emgarten commented Oct 17, 2017

This workaround should be added to the official docs.

@nkolev92 @anangaur

Loading

@brianpos
Copy link

@brianpos brianpos commented Oct 17, 2017

I've tried this out with the Fhir assembly @ewoutkramer, works a treat.
Agree this should be in official docs

Loading

@nkolev92
Copy link
Member

@nkolev92 nkolev92 commented Apr 25, 2020

Hey all,
the NuGet.Client side change has been merged.
However, this is a multi product feature. So I'm working on making sure the experience works end to end before I close this issue.

You can track the effort in the following issues:

dotnet/sdk#10947 The build tasks on (.NET Core SDK side) (dotnet/sdk#11451)
dotnet/NuGet.BuildTasks#70 The build tasks for the non-SDK based PackageReference
dotnet/project-system#6011 Nomination updates on project-system side.

Loading

@nkolev92
Copy link
Member

@nkolev92 nkolev92 commented Jun 12, 2020

With dotnet/sdk#11612 and dotnet/sdk#11954, finally all the legs of this feature are completed.

The feature will be available in 16.7 and all the matching tooling versions (3.1.400 of the SDK, 5.0 of the SDK) & 5.7 of NuGet.exe.

If you are using NuGet.exe, keep in mind that you need VIsual Studio/ MSBuild to be 16.7

Loading

@nkolev92 nkolev92 closed this Jun 12, 2020
@anangaur
Copy link
Member

@anangaur anangaur commented Jun 12, 2020

Awesome!! Thanks @nkolev92 for consistently following up on this one 👏

Loading

@TFTomSun
Copy link

@TFTomSun TFTomSun commented Jun 12, 2020

@nkolev92 can you please provide a link to the documentation / sample?

Loading

@nkolev92
Copy link
Member

@nkolev92 nkolev92 commented Jun 12, 2020

@TFTomSun Design at https://github.com/NuGet/Home/blob/dev/designs/PackageReference-Extern-Alias.md.

I'll update the docs by the time this ships in a GA release.

Loading

@TFTomSun
Copy link

@TFTomSun TFTomSun commented Jun 12, 2020

@nkolev92 are the aliases transistive? I mean, are they applied to indirect, transistive dependencies, too?

Loading

@nkolev92
Copy link
Member

@nkolev92 nkolev92 commented Jun 12, 2020

They only apply to the package reference they are specified on.

The challenge with applying to transitive dependencies is the diamond dependency scenario where: Project -> A -> C and Project -> B -> C.

For the time being the answer to how do I apply metadata to a transitive package still remains elevate it to top level.

Loading

@YanerTavuz
Copy link

@YanerTavuz YanerTavuz commented Jun 26, 2020

Hi!
We're waiting for Visual Studio 16.7 to use this feature, do you know if it's available yet in any of the VS16.7 previews? Saw that Preview 3 was just released.

Loading

@nkolev92
Copy link
Member

@nkolev92 nkolev92 commented Jun 26, 2020

@YanerTavuz Preview 3 should have it

Loading

@YanerTavuz
Copy link

@YanerTavuz YanerTavuz commented Jun 28, 2020

Got it to work with VS16.7 Preview 3.1 and .NET 5 Preview 6 with a .NET project SDK style.

Trying to get it to work with .NET Framework 4.8 with old csproj style,, any tips on how to get it working there? @nkolev92
It works when the csproj is SDK-style, but our solution projects uses the old style.

Edit: After some investigating, it seems that the dll for Microsoft.NuGet.Build.Tasks that is shipped with Visual Studio 16.7 Preview 3.1 does not contain your changes from dotnet/NuGet.BuildTasks#70 so I guess that's the issue.

Loading

@brian-pickens
Copy link

@brian-pickens brian-pickens commented Sep 4, 2020

Will this work to alias different versions of the same package?

Loading

@fubar-coder
Copy link

@fubar-coder fubar-coder commented Oct 19, 2020

Will this work to alias different versions of the same package?

Yes

Loading

@davkean
Copy link
Author

@davkean davkean commented Oct 19, 2020

No, this cannot be used to alias different versions of the same package that has the same identifier. This is entirely used to alias assemblies within a package.

Loading

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