46

Scenario

I'm experimenting with Visual Studio 2015 RC, specifically looking at switching to the new ASP.NET 5 framework, project structure and the new DNX that runs ASP.NET 5 applications.

My employer has many existing solutions targeting .NET Framework 4.5.2. In our existing Visual Studio solutions we might have the following projects:

[Solution] Sample.sln
    [Folder] src
        [Project] ClassLibrary.csproj
        [Project] WindowsService.csproj
        [Project] WebApplication.csproj
    [Folder] test
        [Project] ClassLibrary.UnitTests.csproj
        ...

In this scenario, ClassLibrary.csproj is a C# class library containing shared code. It is a dependency of / referenced by both WindowsService.csproj and WebApplication.csproj.

We aren't specifically trying to target .NET Core, dnxcore50. At this stage we are happy targeting .NET Framework, dnx451. However we are absolutely trying to leverage the new features of ASP.NET 5 and associated project structure.

Below are some options I've thought of but both have issues.

Option 1

When we replace the WebApplication.csproj project above with a new ASP.NET 5 DNX project WebApplication-dnx then we can still reference the ClassLibrary.csproj from both this new DNX project and the existing WindowsService.csproj project. However some issues arise:

  1. This approach means any changes to code in ClassLibrary.csproj need a rebuild to be visible in the running WebApplication-dnx. This isn't surprising but means we do not get full compile-from-source benefits for WebApplication-dnx.

  2. We cannot easily target other frameworks, e.g. dnxcore50. As above, this isn't specifically a goal at this stage.

Option 2

If we replace ClassLibrary.csproj with a DNX class library project^ ClassLibrary-dnx then the problems in option 1 do not apply. This approach would seem to be more in-keeping with the way the .NET runtime and associated technologies such as ASP.NET will be packaged moving forward.

However I cannot find a way to reference ClassLibrary-dnx from WindowsService.csproj. If this approach is viable I imagine the solution has something to do with the project level-option for Produce outputs on build and then referencing the .nupkg or perhaps even the .dll that is produced during the build. However, I cannot see a clean way of achieving this via the tooling.

^ DNX class library projects are called Class Library (Package) in VS 2015 RC. This project type was previously called ASP.NET Class Library in the CTPs.

Summary

Based on the information above I'm looking for:

  1. Some feedback to my scenario options and issues.

  2. Suggestions for other options I have not thought of.

  3. Perhaps an indication of which approach should be used moving forward.

Matt Brooks
  • 1,584
  • 1
  • 14
  • 27
  • Have you considered if `dnu wrap` will work? The wraps .csproj files into project.json files. – vcsjones May 20 '15 at 16:23
  • Yes, my understanding is this is what the tooling now does for you when you add a reference to the .csproj as per option 1 above. – Matt Brooks May 20 '15 at 18:50
  • I have not tried it, so cannot do a full write-up, but for Option 2, you might be able to "Produce outputs on build" of your xproj and then add a local NuGet feed pointing to your artifacts directory to pick up the NuGet package. Maybe I'll get a chance later tonight. – Matt DeKrey May 20 '15 at 18:59
  • Thanks for the suggestion. The problem I see with this, is that the tooling would have to be aware of the local NuGet feed and be able to automatically install new versions of the package into `WindowsService.csproj`. – Matt Brooks May 21 '15 at 13:19
  • That's true, but I think there's a "secret" NuGet.config that you can put at the root of the .sln, too, to list out those locations. But that'd be a real pain to get configured to work completely right, I think. – Matt DeKrey May 21 '15 at 14:50

1 Answers1

22

Take a look at what EntityFramework does.

They target 3 TFMs: net45, .NETPortable,Version=v4.5,Profile=Profile7, frameworkAssemblies and they have both csproj and xproj in the same folder.

Basically, for each project you have two project files.

However I cannot find a way to reference ClassLibrary-dnx from WindowsService.csproj.

Unfortunately, that's not possible, yet. You can only reference csproj from xproj, not the other way around. You have two alternatives: (1) have both xproj and csproj like EF does or (2) reference the NuGet package from csproj.

If you want to do alternative (2) then you can set the output of the xproj to a folder and add that as a NuGet feed.

Julian
  • 33,915
  • 22
  • 119
  • 174
Victor Hurdugaci
  • 28,177
  • 5
  • 87
  • 103
  • Thank you for the references. I will experiment with the approach for (1). You mention 'not possible, yet'. In your opinion, am I facing this problem because the tooling is currently missing support for your suggested workflows (1) or (2) or both? See my [comment](http://stackoverflow.com/questions/30355208/what-are-my-options-for-sharing-code-between-asp-net-5-projects-xproj-and-oth#comment48839618_30355208) above for issues I envisage with workflow (2). – Matt Brooks May 21 '15 at 16:28
  • There is no support per se for your scenario in tooling but you can achieve it with everything that exists publicly today: add a folder as NuGet feed and create a pre build step in the csproj that will invoke NuGet to update the package. Another, simpler way is just to reference the binary produced by xproj rather than the nupkg – Victor Hurdugaci May 21 '15 at 16:33
  • I forgot that point from @VictorHurdugaci - the raw DLLs are output to `{solutionFolder}\artifacts\bin\{xprojName}\{configuration}\{platform}`; you could reference them that way instead of using a folder as a NuGet feed. – Matt DeKrey May 21 '15 at 18:44
  • @VictorHurdugaci I've got a working proof of concept using workflow (1). It currently seems necessary to use two VS .sln files — one for all the .csproj project files and one for all the .xproj project files. This appears to be because VS will not allow two projects to be added with the same name. I'm going to seek input from the ASP.NET team whether we can expect the tooling to improve for this scenario. Thank you again for your input. – Matt Brooks May 22 '15 at 16:24
  • I just asked one of my colleagues. There is no plan yet to support two projects with the same name in the solution – Victor Hurdugaci May 22 '15 at 16:29
  • 1
    Do you know why the entity framework guys are maintaining both versions of solution/project types? Actually, I think there is no real reason because you can target any .net Framework with a new xproj anyways. My guess would be that they don't want to go 100% to the new VS2015/project types because it is still buggy :p – MichaC Jun 02 '15 at 14:58
  • 3
    @MichaC You're guess is mostly correct; we're a very stubborn team. ;) The main thing holding us back, actually, is TestDriven.NET support. – bricelam Jun 02 '15 at 15:54
  • @bricelam haha I see, that makes sense :> Thanks – MichaC Jun 02 '15 at 15:56
  • This [issue being discussed](https://github.com/aspnet/Home/issues/621) is relevant to the topic of this approach being an interim solution. – Matt Brooks Jun 02 '15 at 18:48