Converting a regular class library to ASP.NET 5 (vnext)
I have a problem with library references in one of my existing projects in my new ASP.NET 5 (vnext) project.
I have not found any links online about converting existing libraries or changing the compilation target.
I created a new ASP.NET 5 library and it has a different project structure, so my guess is that there doesn't seem to be a way to port them from VS.
Is there a way to do this other than copying the files? This would create 2 codebases that everyone has to maintain.
source to share
There are 2 solutions:
Share code
You can create an ASP.Net class library and ask it to compile .cs from another class library. To do this, add to your project.json
compile option:
{
...
"compile": [ "**\\*.cs", "..\\Shared\\*.cs" ],
...
}
In this example, the code in the folder ..\Shared
will be compiled with the project code.
Compile your ASP.Net class library for net 4.5
You can create an ASP.Net class library and ask it to target the 4.5 framework. To do this, add to your project.json
add the net45 parameter to the framework
{
...
"frameworks": {
"net45": { },
"dnx451": { },
"dnxcore50": { }
},
...
}
in this example the target 3 project goals are 4.5, ASP.Net full and ASP.Net Core
source to share
The new project system supports compilation for a variety of build targets, including "classic" .NET project types (class libraries, console, etc.). But you need to use a new project system to use it, which copies files to a new project.
The reason this can be very useful is because you can maintain a single codebase if you can partition your code into plaform with blocks #if <framework-target>
to block code that is not supported on any platform. framework-target
in this case is the version of the attachments in the framework in project.json (e.g. NET45, DNX451, DNXCORE50).
It seems to me that the new project system allows a single codebase to serve multiple targets. If your code makes this possible, then it is a good choice for creating multiple outputs at the same time from the same project file. It won't work for everything, but I think it would be a good choice for small and very focused modular solutions.
If your projects require more project-level processing (special tasks ms-build, pre and postprocessing, etc.), then a new separate project probably won't work as well and you're better off using separte projects for each purpose. This may change in the future as more parameters are added to the new project type.
source to share