Sdk: 3 Issues with NET Core Visual Studio Projects

[joshfree]

Moved from https://github.com/dotnet/corefx/issues/10657 on behalf of @MelbourneDeveloper :

Could someone please have a look at the issues I've mentioned here:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/0b8ed5a8-db75-4cbc-85dc-32621a6c749d/net-core-xproj-problems?forum=visualstudiogeneral

The first 2 problems I see as actual bugs. 1 is that conditional compilation symbols don't work in .NET Core projects. The second is that we can't exclude files from the project. This means that I can't get any of our existing code that compiles for Silverlight, NET, UWP to compile in .NET Core.

Also, there is a design flaw with Visual Studio projects that I don't think you can do anything about. All projects have a project.json which means that two projects can't share a folder. This isn't a big problem for csproj projects because we can link files in from anywhere. But, in xproj format, it totally screws everything up because we need to make physical copies of all the files - i.e. it makes it literally impossible to share code.

I've logged the first issue with Microsoft Connect here:
https://connect.microsoft.com/VisualStudio/feedbackdetail/view/2983351/conditional-compilation-symbols-broken-in-net-core-projects

[MelbourneDeveloper]

Has anyone looked at these issues? Is this the right place for these issues?

[rdghickman]

I don't think you are meant to have two projects sharing a directory in the current project.json type layout. We have one solution that uses different projects in different directories and reference one project from the other to share code (the alternative being to obviously use nuget packages). Maybe I don't quite understand your problem though.

That said I am guessing these issues may not be fixed or looked at because apparently project.json is going away again.

[MelbourneDeveloper]

Would someone please read the issues that I've mentioned? Why is the original post closed?

Here is the original post from the MSDN forum. Please take the time to read it and understand what I am saying:

1. Conditional Compilation Symbols Broken

Rather than explain, please download this solution and you will see right away. There is a class defined in the code that is wrapped in a conditional compilation symbol. Even though the symbol is defined, the code is not compiled. It's broken. Enough said.

https://dl.dropboxusercontent.com/u/79781769/Sample%20Apps/ClassLibrary9.zip

Microsoft Connect Report:
https://connect.microsoft.com/VisualStudio/feedbackdetail/view/2983351/conditional-compilation-symbols-broken-in-net-core-projects

2. Can't Exclude Files

I much prefer the new system where files are automatically included rather than excluded. It makes far more sense than the other way around. However, this system is useless unless we are able to exclude files. We have a lot of projects where we can't simply delete files where we don't want the code compiled, because other platform versions need that code, in that place. So, please fix this bug. This sample app shows the bug. I've put some code that doesn't compile in a cs file. Then I hid the file file using the context menu. I thought this would stop the compilation errors, but it doesn't. Please fix this bug. Note: if I've missed something and there is some way to exclude a file, please let me know.

https://dl.dropboxusercontent.com/u/79781769/Sample%20Apps/ClassLibrary11.zip

3. All project.json files, are named project.json

The guy who made this design decision must have said to himself "no user is ever going to want to have more than one project file in the same folder." Well guess what! We keep all of our project files in the same place so that we can compile for many different platforms. This seems to be quite a common practice. However, VS seems to be hard coded so that it always looks for project.json no matter what the name of the project is. This is just plain silly. Why can't we specify a different name so that we can maintain multiple projects in the same folder? This setup means that two projects in the same folder try to use the same project.json.

To answer your question:

_I don't think you are meant to have two projects sharing a directory in the current project.json type layout._

Why not? Developers have been doing this for a long time. This used to be the standard way of handling projects that span multiple platform types. With the introduction of project.json, this was suddenly broken. However, we were still able to work around the issue because we were able to add "link" files.

So, for example, we have a .NET project (csproj), and a Silverlight project (csproj). Both project files sit in the same folder and share 90% of the code files. We then added a UWP project. Annoyingly, when I put the UWP csproj file in the same folder as the other projects, the other projects stopped compiling because they picked up the project.json. This was very frustrating, but I worked around the problem by putting the UWP csproj file in a different folder. After doing this, I manually linked in all the files from the other folder. This was very tedious and time consuming, but at least I was able to continue working and sharing code.

In .NET Core, with an xproj format, this is simply impossible. As far as I can tell, there is no way to link in files from another folder. So, we have to make physical copies of the files that we are maintaining. This is simply impossible. We are not going to maintain two sets of files which are the same, for two different platforms.

_We have one solution that uses different projects in different directories and reference one project from the other to share code_

OK. What is the proposed solution?

_the alternative being to obviously use nuget packages_

NuGet packages? I'm talking about sharing .cs files. I need to share .cs files across project types (.NET, Silverlight, UWP, and .NET Core).

[MelbourneDeveloper]

I've actually figured out what the bug is on dotnet/sdk#4283. The project settings is reading and writing the wrong element to the project.json. Please follow these steps to reproduce the bug, and understand the issue.

Create a new .NET Core Library

Add a conditional compilation symbol called "TESTTEST"

Notice that the symbol is not honoured:

It has added the element "defines" to the project.json

The element is incorrect. It should be "define". See:

Now. The symbol is honoured:

But, the project thinks that the symbol is not defined:

Now, please fix this issue so that other people do not have this much wasted time trying to get their code to compile!!!

[MelbourneDeveloper]

I still need a way to exclude files from an xproj, and I still need a way to be able to share code (.cs files) across multiple xprojs

[MelbourneDeveloper]

https://github.com/aspnet/dnx/issues/3033 is a known issue. How can this not be a high priority?

Isn't the aim to be getting developers to start compiling their code for .NET Core? I'm desperately trying to make this happen so that we can migrate to .NET Core.

[svick]

How can this not be a high priority?

Probably because everything related to xproj and project.json is going away (as was already mentioned in https://github.com/dotnet/corefx/issues/10657#issuecomment-238615298). It doesn't make much sense to spend a lot of effort on code that will only last a few months. That's also why all the tooling is called "Preview 2".

[MelbourneDeveloper]

Yes, but the current xproj structure is going to be imported in to the new csproj format.

Not only that, the problem I have been mentioning about the project.json file is already an issue in csproj.

So, I'm trying to get on the front foot, and get someone to deal with these issues before they become a big problem in the updated csproj format.

Meantime, we've got lots of problems just in trying to get our code compiling for .NET Core.

[MelbourneDeveloper]

Rather than focusing on the xproj format which is now doomed, I have added a suggestion for the new format whatever that may be. I suggest that any given csproj project be able to reference folders from other projects. It would work much like the "link" functionality already existing in csproj formats, but it would reference an entire directory and subdirectories recursively. This would solve many issues and make setting up a project for a new platform a lot easier when the new project needs to share code with an existing project.

The suggestion is here:
https://github.com/dotnet/cli/issues/4033

[MelbourneDeveloper]

Seeing that xproj formats are going to be scrapped.

Is there any way to build a .NET Core project from a csproj file format?

[rdghickman]

I'm still a bit confused about the whole "shared code/cs" thing (I'm probably being daft, but I assumed shared code would be in another project and then either referenced or built as a library/nupkg), but there is a technicality that current project files can actually be *.project.json (eg. main.project.json and other.project.json) and "dotnet build" will be fine with it, and it does appear to restore or try and build both if there are two. Visual Studio really isn't a fan of it though, so I don't really know if that even helps you.

I have basically shelved porting stuff to dotnet core some more until it has stabilised further.

As far as I know, .NET core doesn't do anything with csproj yet because csproj is an MSBuild file, however that is being worked on right now because they are going backwards to this format again. I don't think there has been any official release of that yet, and even then I guess there would need to be another Visual Studio update to handle it.

[MelbourneDeveloper]

rdghickman, apologies to you for only chiming in on this after weeks of frustrating correspondence, but this is getting ridiculous. I logged this problem weeks ago on Microsoft connect and got ignored. Then, someone on the MSDN forums told me to post on GitHub, so I did. Then, someone moved the thread here. I'm totally lost by all the repos etc. that are going on. I've got no idea where my issues are supposed to be posted. Microsoft needs to create an index of all these boards so that people can find the appropriate one. This situation is ridiculous.

Anyway...

_I'm still a bit confused about the whole "shared code/cs" thing (I'm probably being daft, but I assumed shared code would be in another project and then either referenced or built as a library/nupkg)_

I don't really understand what's so hard to understand about this. In the old days, if you were compiling code for two platforms (e.g. Silverlight + .NET), you could lump all the code files in one folder, and have two project files in the one folder. That wasn't an issue in the past. The other option was to used "linked" files from folders outside the folder you are working in. All this is now broken with xproj project files.

_either referenced or built as a library/nupkg_

That's not possible because I'm talking about sharing literal code (.cs files) not libraries. I'm talking about taking the same code and compiling it for two different platforms.

_there is a technicality that current project files can actually be *.project.json (eg. main.project.json and other.project.json) and "dotnet build" will be fine with it, and it does appear to restore or try and build both if there are two. Visual Studio really isn't a fan of it though, so I don't really know if that even helps you._

This doesn't sound like it will help me because an xproj project will pick up all project.json files because there is no way to explicitly include or exclude files.

Anyway, what I am doing to work around all these problems right now is to make the code changes in the original project, and then I am running a batch file to copy the cs files to the xproj project. It's a horrible hack that wastes a lot of time, but I'm at least getting close to compiling my code in .NET Core.

[rdghickman]

I see, I think I got the wrong end of the stick. I have built .NET core projects simultaneously for netstandard and net45 runtimes in a single project but not entirely different platforms in the same project.

So yes, I think part of your problem is why they have given up on project.json (sadly). You can specify multiple frameworks and so on in project.json but I think supporting all the different platforms isn't done yet, and for whatever reason, they think this is going to be easier by abandoning the new structure and going back to the clunkier, but presumably more feature-rich csproj format and then have MSBuild deal with the complexity.

I think even if you could exclude in the project.json it's not going to work because Visual Studio seems to choke a bit if you deviate from this fixed naming (even though the CLI seems ok). From my own limited experience .NET core seems ok for libraries and simple apps right now, but it's not ready for prime time on complicated stuff. I don't really have any other suggestions to offer, and I suspect the .NET core teams are flat out trying to suddenly change 90 degrees to cope with the project format change again.

Frankly I'm not even sure if your other bug about compilation symbols is a .NET core thing or a Visual Studio .NET core extension issue, and I don't know where to post issues about the latter...

[MelbourneDeveloper]

I have logged the second issue I mentioned (not being able to exclude files) here:
https://github.com/aspnet/Tooling/issues/723

_I see, I think I got the wrong end of the stick. I have built .NET core projects simultaneously for netstandard and net45 runtimes in a single project but not entirely different platforms in the same project._

TBH, I'm getting really confused about all the different assembly types and runtime environments now. I used to just compile for .NET and Silverlight. Now, I have to compile for Silverlight, .NET, .NET Core, Xamarin, and Windows UWP.

I'm hoping that the .NET Standard (protocol?) helps to consolidate some of this work. I've now got half of our libraries compiling for .NET Standard 1.4 which happily allows me to leverage our DLLs for compilation in .NET Core. However, Once I switched to 1.4, I could no longer reference the Xamarin Forms NuGet package, which makes me think that .NET Standard dlls won't work with Xamarin. Why 1.4? That's the highest .NET Standard version that the NuGet packager allows. Why? Don't ask me.

_So yes, I think part of your problem is why they have given up on project.json (sadly)._

They have given up on project.json? Whoa. That's news to me. Since when? And how is our environment going to be thrown in to upheaval this time?

_Frankly I'm not even sure if your other bug about compilation symbols is a .NET core thing or a Visual Studio .NET core extension issue, and I don't know where to post issues about the latter..._

I've proven beyond a shadow of a doubt that this problem exists in the xproj format. It's a simply spelling mistake in the project.json. I have completely documented the issue at the top of this thread. I realise that they are going to dump xproj, but how long do we have to wait until the next thing comes in? We're developers here. We're trying to write code, not spend 8 hours a day digging through the guts of the tools to try to figure out why we get obscure error messages when we compile. We just need Microsoft to settle on a project format and allow us to start writing code rather than putting together a jigsaw puzzle.

[rdghickman]

I think the information we have been given so far has been detailed here: https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/

I don't know of any ETA on this personally.

[TheRealPiotrP]

@rdghickman we had enabled msbuild tooling in CLI in preview3 [we've since shipped preview4 and are now working on rc3]. You can get the latest rc3 installer from the home page of this repo. You can run dotnet migrate from the root of your solution directory to move to the msbuild project system and try out the new project format + capabilities. Let us know if you see any issues!

@MelbourneDeveloper thanks for the detailed writeup you're touching on a lot of issues we experienced with project.json + xproj. The three issues you called out have been addressed:

1. Conditional Compilation Symbols Broken
   These now have the same handling as they have historically in msbuild.

2. Can't Exclude Files
   By default, the csproj file will include **/*.cs. However, you can override the default globs and exclude particular files/patterns.

3. All project.json files, are named project.json
   Project files are now called foo.csproj, where foo can be anything folks like :)