Referencing a DLL

[plioi]

I'm currently blocked from migrating a project to .NET Core due to my need to have an xproj/project.json project reference a DLL directly. The DLL is made by a third party and is not available as a NuGet package. In the past, we could reference another project in the same solution, a NuGet package, or a DLL. The third option seems to have been removed.

Other traffic from before the .NET Core RTM suggested creating a project whose sole purpose is to wrap the DLL, and to configure that wrapper package like so, but it appears to have no effect now:

"frameworks": {
    "net452": {
        "bin": {
            "assembly": "relative path to the dll"
        }
    }
}

The project which needs to reference this DLL happens to only need to target net452.

If I right-click a project, Add Reference, select Assemblies, Browse, and select the DLL, I get the following dialog:

.NET Core projects only support referencing .NET framework assemblies in this release. To reference other assemblies, they need to be included in a NuGet package and reference that package."

But, this is a .NET framework assembly.

[akoeplinger]

".NET framework assemblies" in this case means the BCL, like System.dll etc.

The NuGet docs show how to create a package from a dll: https://docs.nuget.org/create/creating-and-publishing-a-package. You can put that nuget package in a local folder and use that as a feed: https://docs.nuget.org/create/hosting-your-own-nuget-feeds

[plioi]

Thanks, @akoeplinger. This approach worked. To ensure the project works well for people who clone from scratch, I also included a nuget.config in the root of the project which defines the relative path to the local package source:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="api.nuget.org" value="https://api.nuget.org/v3/index.json" />
    <add key="local" value="lib" />
  </packageSources>
</configuration>

I believe this issue can be closed now.

[CoreyKaylor]

In this scenario would dotnet pack create a nuget dependency for something only available on your local filesystem feed?

[blackdwarf]

@CoreyKaylor dotnet pack will create a nupkg of the project you point it to. It will create a nuspec for any dependencies that exist in the project it is packing. It is on the packager to make sure those are in an accessible place so that the consumer can reach them.

I will close this issue as per @plioi comment above.

[CoreyKaylor]

@blackdwarf I'm aware of how dotnet pack works, but thanks. I was more trying to call out that the original statement of "is not available as a nuget package" and this workaround now creates a new problem that also needs to be worked around by managing your own nuspec when the tooling should handle all of those details for you. I'm glad it works for his needs though.

[oldman1991]

@plioi
Is it added in the web.config or other files？thanks

[plioi]

@lipeng1991 The XML that I posted above? "nuget.config in the root of the project"

[oldman1991]

@plioi yeah，i have seen it ,but I want to konw 'local' and 'lib' represents what.thanks

[plioi]

@lipeng1991 Take a look here: https://github.com/fixie/fixie/tree/df2b201a178a6da736699ffa6757548ceebfa0d1

The nuget.config file is here, and there is also a folder called "lib" (short for "libraries"), where I put nuget packages. "local" is just a name for that line in the XML and I could have chosen a different name.

[oldman1991]

@plioi yeah thanks for your answer,if i have added this config,what should i do next?

[oldman1991]

@plioi but this project does't have a project.json file

[plioi]

@lipeng1991 If your project doesn't have a project.json file, then this whole issue is irrelevant to you. I suggest posting a very specific question about what you're actually trying to accomplish at stackoverflow.com

[lilpug]

i don't quite understand how this has been closed off, this issue still persists 2 months later and there is no ETA on the fix for this nor a mention that i can find, having to support local feeds and create nuget specifications to just add a .net dll library which could be a private library seems daft. There are so many issues opened across all dotnet core git repositories for this one issue, would it not be wise to look at addressing it or at least explain why the issue persists at the moment rather than sitting on it?

http://forums.asp.net/t/2100395.aspx?Can+t+Add+Net+4+6+Reference

aspnet/Mvc#4682
dotnet/aspnetcore#1612
aspnet/Tooling#565
aspnet/Tooling#700 (comment)

[jgauffin]

Reopen this. See the comment by @lilpug. This has a big impact on enterprise development, as many of us are not willing to generate nuget packages for internal DLLs.

ping @blackdwarf

[mellinoe]

Since we are moving all of the tooling to use MSBuild, we most likely aren't going to be investing in fixes for problems like this in the json-based project system. MSBuild will/already does support this particular scenario (just add a <Reference Include="<path.dll>">).

[MeTitus]

This shows how bad MS guidance is nowadays when it comes to release new technologies... this .NET Core tooling is nothing but a whole mess.

[ct14it]

@mellinoe So basically you don't recommend going with the current solution of packaging up a DLL in a nuget package? The proper solution is/will be adding a reference to the DLL? I'm confused as to how this is different to the original way of doing things, which was to just add a reference to the DLL?

Are you able to point me in the right direction for using MSBuild and specifically if possible referencing an external DLL with a core app? Any feedback would be greatly appreciated because I would love to use Core for proper projects.

[mellinoe]

I wasn't making any recommendations about what anyone should do, necessarily; it all depends on your project, its requirements and restrictions, etc. The original question was about how to reference a binary directly rather than through a nuget package, so I was just answering that question.

Are you able to point me in the right direction for using MSBuild and specifically if possible referencing an external DLL with a core app? Any feedback would be greatly appreciated because I would love to use Core for proper projects.

Right now, the best thing to do is to go to https://github.com/dotnet/cli and download one of the latest preview CLI's. There is also preview support available in VS 2017 RC, available for download.

[jmbeach]

@plioi I can't get VS 2015 to recognize the nuget.config. Should it? After adding it, VS does not have a "local" package source.

[jmbeach]

Nevermind. Got it to work, by referencing at the solution level

[jmbeach]

Okay, I still have a problem. I am trying to turn several dlls from this OPC project into a nuget package to use locally. I put the dlls in a lib folder:

D:.
└───lib
    └───netstandard1.6

I packaged the nuget package using this nuspec:

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
	<metadata>
		<!-- The identifier that must be unique within the hosting gallery -->
		<id>Opc.Core.Ua</id>

		<!-- The package version number that is used when resolving dependencies -->
		<version>1</version>

		<!-- Authors contain text that appears directly on the gallery -->
		<authors>OPC Foundation</authors>

		<!-- Owners are typically nuget.org identities that allow gallery
				 users to earily find other packages by the same owners.  -->
		<owners>jmbeach</owners>

		<!-- License and project URLs provide links for the gallery -->
		<licenseUrl>https://opcfoundation.org/license/gpl.html</licenseUrl>
		<projectUrl>https://github.com/OPCFoundation/UA-.NETStandardLibrary</projectUrl>

		<!-- The icon is used in Visual Studio's package manager UI -->
		<iconUrl>http://opcfoundation.github.io/UA-.NETStandardLibrary/images/OPCF_250px_72ppi_RGB.jpg</iconUrl>

		<!-- If true, this value prompts the user to accept the license when
				 installing the package. -->
		<requireLicenseAcceptance>false</requireLicenseAcceptance>

		<!-- Any details about this particular release -->
		<releaseNotes>init</releaseNotes>

		<!-- The description can be used in package manager UI. Note that the
				 nuget.org gallery uses information you add in the portal. -->
		<description>.NET Core implementation of OPC foundation UA tools</description>

		<!-- Copyright information -->
		<copyright>Copyright c2016 OPC Foundation Corporation</copyright>

		<!-- Tags appear in the gallery and can be used for tag searches -->
		<tags>opc ua net core</tags>

		<!-- Dependencies are automatically installed when the package is installed -->
		<references>
			<reference file="Opc.Ua.Client.dll"/>
			<reference file="Opc.Ua.Configuration.dll"/>
			<reference file="Opc.Ua.Core.dll"/>
		</references>
	</metadata>
</package>

But when I try to add it to my .NET core project in Visual Studio 2015, I get the following error:

Errors in D:\Code\GitHub\<my-project-path>
    Unable to resolve 'Opc.Core.Ua (>= 1.0.0)' for '.NETStandard,Version=v1.6'.

Opc.Core.Ua is what I named the package.

I don't know if the dlls aren't built to NetStandard version v1.6, but they compile to a folder called 'netstandard1.3'. Any pointers would be much appreciated.

[Petermarcu]

Are you able to move to the previews of VS 2017? There were a lot of issues in the Preview tooling in VS 2015 around references. Many have been addressed in VS 2017 and if they aren't thats where people will want to know very soon so they can be fixed.

[jmbeach]

I'll try that.

[jmbeach]

@Petermarcu This worked. I'm not sure if it's because I was targeting ".NET Core" in VS 2015 and now I'm targeting ".NET Standard" or what the difference between the two is (to be honest).

Thanks for the help.

[Petermarcu]

Glad you got past it. Tons of things already work better in 2017 and it's getting better everyday. I think another prerelease update to RC3 is coming very soon with more fixes.

[jmbeach]

I ended up switching back to VS 2015 because VS 2017 was glitching out on me and saying "opening file..." forever when I tried to open my solution.

I got it working, by creating a portable class library, converting it to .NET Standard by following this blog post's instructions and then installing my NuGet package.

[pekunicki]

Guys, I've question, because I see that you probably have similar issue.
I'm working on the .NET Core WEB API project, but it's builded on the .NET Framework.
I've Unit Tests in different library in .NET Framework. Unfortunately I can't get refernces to .net core projekt in .net framework. Do you have some workaround ? ;)

[WallaceKelly]

For the record, this issue is also discussed at https://github.com/dotnet/coreclr/issues/10037

The conclusion is the same as what @mellinoe suggested. Use <Reference Include="<path.dll>"> .

[xplicit]

@WallaceKelly how to use <Reference Include="<path.dll>"> if it does not work? You showed the sample in https://github.com/dotnet/coreclr/issues/10037#issuecomment-289138830 which clearly describes this bug with <Reference Include="">. How did you workaround this issue?

In previous version of .NET Core SDK (-3177) with project.json it was possible to reference dlls without creating nuget packages (by creating the wrapping project), but with moving to new csproj system it does not work anymore. How to use external dlls without creating nuget packages for them?

[WallaceKelly]

@xplicit My conclusion was that the current toolset does not support referencing loose DLLs.