Open MelbourneDeveloper opened 8 years ago
I'm not asking for a definitive answer here...
I just need a rough idea of what is going on so that we can make some decisions around development.
Do we proceed with configuring our projects so that much of our code referencing is done inside the project.json like xproj projects?
Is the project structure about the change so much that it's not even worth pushing ahead with ASP .NET Core projects in the meantime?
@MelbourneDeveloper
See: https://oren.codes/2016/02/08/project-json-all-the-things/
This is a useful article, but it's pretty outdated, and doesn't answer my question at all. This guy is talking about project.json as though it pertains almost purely to NuGet. Since then, the xproj format has completely changed the game to the point where configuration for the project (not just NuGet config) is done almost solely in the project.json file. He's talking about the xproj format as though it is "new". Well, it's kind of new, but everyone is saying it's already going to be dumped. So, we need to know, what is next? How should we orient our development? Should we bet that the xproj structure is going to be continued? Or was it just an experimental stab in the dark that will get dumped?
Is anyone on this repo here willing to stick their neck out and give us some indication of what will happen?
Will xproj be continued? If not, what's next?
No, it will not be continued. See the "Q4 2016 / Q1 2017" section of https://blogs.msdn.microsoft.com/dotnet/2016/07/15/net-core-roadmap/
That's what people are saying. But what will the new csproj format look like? Will it have any similarities to xproj or project.json? Meantime, we are still forced to use xproj.
There's a lot of design in-progress ... https://github.com/dotnet/cli/issues/4096 https://github.com/dotnet/cli/issues/3819
You can dig around to see samples from test projects. For example, here's one from EF: https://github.com/aspnet/EntityFramework/blob/40c1d38f7d87dfbb99d61713fc15c7063f896a6b/src/Microsoft.EntityFrameworkCore.Design.Core/Microsoft.EntityFrameworkCore.Design.Core.csproj
Minimal example from a test app in cli repo: https://github.com/dotnet/cli/blob/rel/1.0.0/TestAssets/TestProjects/MSBuildTestApp/MSBuildTestApp.csproj
I cobbled one together in a just-for-fun project (https://github.com/GuardRex/GuardRex.JsonToCsprojConverter) that worked when I created it (it was for an AST.NET Core self-contained app): https://gist.github.com/GuardRex/1b4ee7d29e870ce182d587144aa33768 (but I wouldn't be surprised if there were deltas since I did that)
@davidfowl has one in one of his repos: https://github.com/davidfowl/AspNetCoreCsproj/blob/master/MyWebApplication/MyWebApplication.csproj
There are probably more sample/test apps out there in various states with csproj files. We can see by the tracking issues above tho that a lot of important bits are still in-design, such as multiple TFM's and packOptions
.
Thanks. I came across this article today: http://ivanz.com/2016/05/17/farewell-project-json-hello-msbuild-and-csproj
Basically the question that I have right now is given that I have some ASP.NET Core (.NET Framework) project, is there some way I can build this with MSBuild?
So, is there some way I can use this example projects somehow? Wouldn't I have to download experimental VS code or something to get these to work? Or will they just work in Visual Studio 2015? I'm happy to run things at the command prompt if it means getting off xproj. Xproj is a nightmare.
There is a very rudimentary way but that probably will only work with the simplest of projects.
https://docs.microsoft.com/en-us/dotnet/articles/core/tutorials/target-dotnetcore-with-msbuild
There are a ton of WIP going on with the nightly bits, and trying to use nightly stuff for it probably would be rough (if its even possible). https://github.com/dotnet/cli/issues/3819
Thanks.
So, be honest here. Should I just give up on ASP.NET Core until xproj is converted to csproj?
Our solution is fairly complex and I need to something stable to work on.
The problem is when you have things that you're doing with dotnet cli
based on config in project.json
that has no equivalent in MSBuild. Like if you have some important buildOptions
things in project.json
specific to dotnet cli
tooling or you're using tooling
section tools. If your project is simple vis-a-vis what you're doing in project.json
, it might work.
It seems in VS 2017 RC and VS Mac Preview, Core applications now use a CSProj with new file inclusion rules.
I've just installed VS 2017 RC and found there's no support for .NETStandard 1.6 project. I also did dotnet migrate
of project.json
and resulting .csproj
file was generated quickly, but now dotnet test
does not run complaining about:
Error: Failed to initialize client proxy: could not connect to test process.
We're going back to VS Code as some of the team members including myself use Linux for development.
@dmumladze @MelbourneDeveloper @ChristianSacramento @GuardRex @glennawatson Are there any official blog post or documentation on this subject? Thanks in advance,
@natemcmaster put up a nice one at http://www.natemcmaster.com/blog/2017/01/19/project-json-to-csproj/
I also recommend that you cruise around on the repos looking at tests and samples. The doc samples and examples aren't going to move to MSBuild/csproj
until closer to release. I did one, the Key Vault Configuration Provider doc, as an MSBuild/csproj
project, and you can see the direction samples will take with that one (but it isn't fully baked yet and will prob see more changes by the time the doc releases): https://github.com/GuardRex/Docs/blob/guardrex/key-vault-configuration/aspnetcore/security/key-vault-configuration/sample/KeyVaultConfigProviderSample.csproj
[EDIT] I'm also in the process of getting a small footprint self-contained app running. https://github.com/GuardRex/testselfcontained/blob/master/testselfcontained.csproj <- However, there are a few :beetle: bug-a-boos with it, so it almost works.
@gmartinezsan My main issue is/was limited support in VS 2017 RC for .NETStandard 1.6 based projects, but as for.xproj
files (or project.json file), I found it easier to just manually update version numbers of all dependencies in them to the latest ones. Then I installed the latest tools/SDK and did dotnet migrate
for each project, which then produced .csproj
files.
EDIT: I haven't tried the latest update for VS 2017 yet
One of the improvements you may be interested in (assuming you're on windows)
Updated .NET Core and ASP.NET Core – No longer a preview workload. Fixed several bugs and improved usability of .NET Core and ASP.NET Core tooling. Project migration from project.json/xproj to csproj is much more reliable.
@dmumladze @GuardRex @glennawatson Thank you for the posts.
Our projects are targeting .net 451 and net standard 1.6, and net core app 1.0.0 for the Unit tests projects. It took us a time to make them stable. But if the xproj is going to be deprecated we will have to return to csproj soon. So last question is should I use VS 2017 for the project migration? Thanks for the hints.
I'm still on VS Code for web dev and VS 2015 for Xam projects. Some of the devs on Slack are using VS 2017, and they can let you know how things are going. Especially hit up @ArieJones to see how he's faring with it ... I do. 😉 http://tattoocoder.com/aspnet-slack-sign-up/
[EDIT] Also note that the dotnet migrate
command has been better lately (get latest CLI for the latest version). They've been working on it steadily AFAICT. You can try some migrations from the command-line with it and see how it goes.
@GuardRex will check with the CLI tool. Thanks a lot!
I will post my results here.
The latest version of of Visual Studio projects for .NET Standard 2.0 are very similar to xproj. It looks like a lot of the code for xproj has been merged in to the latest csproj format.
The main problem I have with the latest format is that code rules don't work.
We are deep in ASP .NET Core development...
Obviously, the xproj format is fraught with issues. That's OK, we only have the tooling preview currently.
But, what's next? Is there a future for xproj? If xproj is dumped in favour of csproj, will the new version of csproj use the same functionality as xproj? I.e. will it favour configuration in the project.json over the csproj itself? When can we expect the new version of csproj?