How to alias a package?

[singlewind]

Previously, when we have a same namespace class sits in different dll files we can use extern alias to distinguish them.

I don't know how to deal with nuget package in project.json file.

An example will be

Severity Code Description Project File Line
Error CS0433 The type 'HMACSHA1' exists in both 'System.Security.Cryptography.Algorithms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' and 'System.Security.Cryptography.Hashing.Algorithms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' Hema.Auth.Identity.DNX Core 5.0

[alex4998]

Why the issue was closed? Was it resolved? How? I have exactly the same question.

[joshcomley]

@alex4998 did you figure this out?

[singlewind]

In .NET Core, use "same dll" with multiple version is allowed. because the dll files are no longer sit in bin folder together. It has been referenced as a package. The problem I referenced previously, it was caused by break changes of interface. Somehow, the referenced version hasn't been updated to reflect the changes. For example, we have referenced a package System.Security.Cryptography.Algorithms: "1.0.0.*", which means compatible all the packages 1.0.0.0 up, includes beta and alpha. If break changes has been introduced inside any of compatible version. And our system will try match and get the latest package on our system. Then it breaks.

[alex4998]

I understand that but it does not explain how to use aliases with referenced assemblies of the referenced package. Once again, my situation is this. I reference Google Drive API v2 package which has a lot of dependencies and one of those dependencies have exactly the same class name which results in a bunch of compiler errors because of the naming collision. Let’s say I have a namespace MyApplication.Library and there is class TaskEx. One of the package dependencies have a namespace System.Threading and there is TaskEx too. In some of my sources I have “using MyApplication.Library” and “using System.Threading” (with this using I didn’t refer to the package dependency assembly, I referred to the system System.Threading but it happened to have the same namespace). In these conditions I’m getting the naming collision errors from the compiler everywhere I’m using TaskEx. With the NuGet v2.* the situation can be easily resolved changing dependent assembly aliases from ‘global’ to let’s say ‘google’ and everything compiles after that. With the NuGet v3.0 I don’t know how to change dependency assembly aliases to fix my problem. So, I’m looking for a workaround and hope on a resolution of this lack of functionality in the future versions.

Thank you,

Alex

From: Yue Zhou [mailto:notifications@github.com]
Sent: Saturday, March 5, 2016 18:09
To: dotnet/core core@noreply.github.com
Cc: alex4998 alex.49.98@gmail.com
Subject: Re: [core] How to alias a package? (#14)

In .NET Core, use "same dll" with multiple version is allowed. because the dll files are no longer sit in bin folder together. It has been referenced as a package. The problem I referenced previously, it was caused by break changes of interface. Somehow, the referenced version hasn't been updated to reflect the changes. For example, we have referenced a package System.Security.Cryptography.Algorithms: "1.0.0.*", which means compatible all the packages 1.0.0.0 up, includes beta and alpha. If break changes has been introduced inside any of compatible version. And our system will try match and get the latest package on our system. Then it breaks.

—
Reply to this email directly or view it on GitHub #14 (comment) . https://github.com/notifications/beacon/AOUds8D7lmjZAhLqacnDfjgEH31Vq6bCks5pqhsvgaJpZM4Fwv6n.gif

---

This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[singlewind]

You always can use "using" to alias a namespace. In our source code, on the top using statements section, add "using my = MyApplication.Library", then you can use "my.TaskEx" just like how .NET works before.

[alex4998]

Right. It works as a workaround but ideally, of course, I’d like to be able to change aliases on the dependency assemblies. Simply because in this case I don’t need to change a single line in the code. With using aliases I at least need to change all the usings and change the lines referring those usings.

Thanks anyway,

Alex

From: Yue Zhou [mailto:notifications@github.com]
Sent: Sunday, March 6, 2016 16:15
To: dotnet/core core@noreply.github.com
Cc: alex4998 alex.49.98@gmail.com
Subject: Re: [core] How to alias a package? (#14)

You always can use "using" to alias a namespace. In our source code, on the top using statements section, add "using my = MyApplication.Library", then you can use "my.TaskEx" just like how .NET works before.

—
Reply to this email directly or view it on GitHub #14 (comment) . https://github.com/notifications/beacon/AOUds9pVQXVd310rtE1HA4uyYi0WYh9Hks5pq1HzgaJpZM4Fwv6n.gif

---

This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[toddmo]

In my case the type's fullname is duplicated in two assemblies. And I can't use extern to differentiate.

[UnoSD]

I think this issue should be open, too. I referenced FSharpx.Extras and FSharp.Control.AsyncSeq which both define a FSharp.Control.AsyncSeq module. There is no way to resolve this issue and I ended up removing FSharpx.Extras. They both have the same full name so aliasing modules (as using ... in C#) does not help.

[Petermarcu]

This should probably be opened in the Nuget/Home repo.

[dasMulli]

There's a NuGet issue already with the current "workaround" being to write a custom target like
NuGet/Home#4989 (comment)

[UnoSD]

thanks @dasMulli

EDIT: that doesn't work on F# :( no extern alias

[dshalin]

What a perfect support of doing nothing!

Still no reaction to the pain of developers?

[karelz]

@dshalin the issue was closed by the person who created it. We do not comment or reply to comments on closed issues.
If you believe there is still some gap here, please file clear description of the problem in the right repo (this issue is somewhat long and not quite clear to me).