Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Support extern aliases in DNX

See original GitHub issue

From @PinpointTownes on August 8, 2015 20:9

Though not very popular, extern aliases are useful to work around CS0433 Type 'X' already exists in both 'A.dll' and 'B.dll' compilation errors, specially since we can’t exclude transitive dependencies yet.

Copied from original issue: aspnet/dnx#2445

Issue Analytics

State:
Created 8 years ago
Reactions:4
Comments:9 (3 by maintainers)

Top GitHub Comments

2reactions

PavelSafronovcommented, May 25, 2016

Any updates on this issue or if there is a way to accomplish the same with the current releases?

1reaction

fubar-codercommented, Jul 19, 2016

I found a hack that worked for me by (ab)using NuGet.Config and additionalArguments in project.json.

First, add a NuGet.Config with the following content:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="globalPackagesFolder" value="../../packages" />
  </config>
</configuration>

Now, use buildOptions/additionalArguments in your project.json:

    "additionalArguments": [
      "/r:alias1=../../packages/Assembly1/1.0.0.0/lib/net45/Assembly1.dll",
      "/r:alias2=../../packages/Assembly2/1.0.0.0/lib/net45/Assembly2.dll",
      "/r:alias3=../../packages/Assembly3/1.0.0.0/lib/net45/Assembly3.dll"
    ],

This is a lousy hack, but it works as long as you explicitly specify the package version in the package dependency.