7

In our current environment, we have some shared common library (C# Class Library .NET 4.5.1 csproj) projects that are referenced by both asp.net and console applications. We are looking into upgrading 1 of our web projects to ASP.NET 5 to start testing out some of the new changes coming.

Since I can't do a project reference in ASP.NET 5 to the old csproj library type, I have to reference the library by it's compiled DLL and remove dnxcore50 from project.json (which is fine for us). However, We own the shared library source and constantly bring down updates in our DEV environment for modifications and changes will be needed often to the DLL. ASP.NET 5 puts the DLL inside of a lib directory and does not use a path to the csproj directory.

What would you do if you have asp.net & console csproj apps along with asp.net 5 apps needing to share a common code library without having to maintain 2 code bases? Would you recommend a build task to compile the common library project and replace the reference DLL in lib before compiling the asp.net 5 project or instead setup a local nuget repo for our shared library since project references are out of the question now for csproj? We're a shared team with all of this code in TFS so whatever I do needs to be replicated easily for everyone else.

Improve this question

1 Answer 1

Reset to default
2

If the shared code doesn't change to often, I would go with a shared nuget repository. This way, you get all the benefits of using nuget packages: versioning, easy restoration, etc. Your solution can have less projects and compile faster. But if the shared code is constantly changed, going through pack-push-restore process could be painfull.

There is one other way - dnu has a handy command named wrap. It wraps your existing .csproj files into project.json files that can be then referenced by aspnet5 projects.

You can do something like this:

  1. Add a global.json file in the some top-level directory that contains your projects. In the projects section, list directories that contain your source-code, for example:

    { "projects": [ "src", "test" ], "sdk": { "version": "1.0.0-rc1-final" } }

  2. In the same directory that contains global.json execute dnu wrap for each existing .csproj project.

    dnu wrap src/my.project/my.project.csproj

    This should create a directory wrap containing project.json files that wrap .csprojs. A sample file looks like this:

    { "version": "1.0.0-*", "frameworks": { "net45": { "wrappedProject": "../../src/my.project/my.project.csproj", "bin": { "assembly": "../../src/my.project/obj/{configuration}/my.project.dll", "pdb": "../../src/my.project/obj/{configuration}/my.project.pdb" } } } }

    Note that wrap directory is also added to projects section in global.json.

  3. In your solution, add a new aspnet project and add a reference to the wrapped project. Just add:

    "my.project": ""

    to dependencies section. Aspnet should automatically pick up global.json file in root directory, and will look for projects in all directories listed there, including wrap directory.

  4. Now you're good to go - you can use all classes from my.project, step into them while debugging, go to definition, etc. Note that in your solution, you still have the old csproj.

You can find a sample code here: https://github.com/heavymetaldev/aspnet5-wrap.

I suppose this may get a little complicated if you have some custom things in your projects, like conditional compilation, custom includes, etc.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.