How do you add references to locally created NON ASP.Net 5 dlls to an ASP.Net 5 project

Question

The asp.net home wiki appears to indicate that one can add references to locally produced dlls (assemblies) via the "bin" wrapper. However, it appears that only one bin wrapper may be included in a project.json file. So, what is the correct way to add references to external class library dlls compiled against .net framework 4.6 and portable library .net framework 4.6?

BTW. These DLLs are not in the same solution as the ASP.Net project.

Answer 1

Here is the accurate location of "bin syntax" in wiki https://github.com/aspnet/Home/wiki/Project.json-file#bin-syntax-wrapping-a-dll

The wiki reads:

You can create an project that, instead of compiling, references an already compiled dll and generates a package containing that dll

Please note that, with the "bin syntax", you are creating a project that uses the wrapped dll as its output (instead of compiling some source code to get the output dll). You are NOT adding a dll as a reference of target project.json.

Here is an example of the correct way to use "bin syntax" when you want to add a reference to a dll:

Assume we have:

• ASP.NET 5 project, ProjectA
• ClassLibraryB.dll, which was produced by some other type of project

To add a reference from ProjectA to ClassLibraryB.dll, we need to create a wrapper project wrapping ClassLibraryB.dll:

1. Create a folder ClassLibraryB

2. Create a project.json in ClassLibraryB folder with the contents:

   {
     "frameworks": {
       "dnx451": {
         "bin": {
           "assembly": "<path to ClassLibraryB.dll>"
         }
       }
     }
   }
   

3. ClassLibraryB is an ASP.NET 5 project, add a reference from ProjectA to it as usual.

Answer 2

Nearly a year later, I was able to get a reference to a non-local dll included and compiled against. There are some missing and mis-understood steps that need to be followed.

Along my journey over the past year, I could not find any of the many previously named versions of the DNX utility. Just recently, I found an article that says you must run DNVM to pick a version of the runtime. Once that is done, the path to DNX is placed on the path variable. Do not forget to start a new copy of CMD (or PowerShell) at that point to pick up the new environment variable. Also note that the .dnx folder is a hidden folder and will not show with a dir command or in windows explorer unless you have turned off hide hidden folders. See Stack Overflow question "DNX does not work" for more discussion about running DNVM.

Once the dnx environment is setup, dnu wrap can be run. First problem is that you must have a global.json file in the solution folder. This file is not created by default and the documentation for what should be in it is next to non-existent. The file needs to have minimal information in it.

{
"projects": [
    "web"
    ],
"sdk": {
    "version": "1.0.0-rc1-update1",
    "runtime": "clr",
    "architecture": "x86"
    }
}

In my example, web is the name of the only project in the solution. Others may be added as required. Once created make the solution directory the current directory and then issue a dnu wrap command.

dnu wrap full_path_to_an_assembly -f framework_version

To be honest, I am not completely sure of what can/should go in as the framework version. I used dnx461 as that was the version of the framework against which I had compiled the dlls. The output of the dnu wrap operation will go into the "wrap" folder under the solution folder and the global.json file will be updated to include the wrap project (folder) in the projects section.

Since this process seemed like a lot of work for including several dlls in every new solution, I manually created the project.json files for the wrapping and placed them in a global location (right next to from which a normal .net assembly would reference them). I then placed the full path to that folder as a project in the global.json file and I was able to add references and compile. One issue was that even though relative paths are supported, there appears to be some confusion as to what they are relative too. I had to include the full path of the binaries (and pdbs) in the project.json files that provide the binary wrapping. Example project.json for wrapping a binary

  {
    "version": "1.0.0-*",
    "frameworks": {
      "dnx461": {
        "bin": {
          "assembly": "../../bin/log4net.dll"
          }
        }
      }
  }

Note the use of the relative path above. That does not work correctly. Change that to a full path to the assembly in question.

The good news, is that once everything is setup correctly, intellisense in Visual Studio for the dependencies section of the project.json will indicate the name of the dll as you type it in.