Aspnetcore: Discussion: Updates to project.json schema

[ajaybhargavb]

Discussion for aspnet/Announcements#175

[smbecker]

Where should define go? I didn't see it in the list of changes but I assume that compilationOptions is going away entirely.

[smbecker]

Also, does this affect the shared option?

[ajaybhargavb]

Where should define go?

compilationOptions is being renamed to buildOptions. So all options including define still exists in buildOptions.

Also, does this affect the shared option?

No. shared still exists and is not deprecated.

[guardrex]

@ajaybhargavb Is copyToOutput functional?

I added ...

"copyToOutput": {
    "include": [ "Views", "wwwroot", "Logs" ]
}

... to buildOptions, but Debugging in VS Code fails to trigger these folders into Debug. I also tried dotnet build -f netcoreapp1.0 -r win81-x64 -c Debug, which also failed to get these folders/files into output. [CLI version -2609]

[Tasteful]

Is it possible to some type of global version numbering?

When using DNX it was posible to use the DNX_BUILD_VERSION environment variable to change the * part of version number 1.0.0-*. If you have say 20 different class assemblies that always is released together and the version number for them should always be the same, can I set an environment variable for that or use global.json. I mean the 1.0.0 part so that can be set on global way to 2.0.0 without changing all the individual project.json:s.

[guardrex]

@Tasteful It's been backlogged ... https://github.com/dotnet/cli/issues/551 and https://github.com/dotnet/cli/issues/549

[Alxandr]

What about "debugType"?

[smbecker]

Is it expected that if I specify "includeFiles" that I also need to specify "include"? In one of my apps, I am including a file from a different directory. When I do that, I get an error that states that Program does not contain a static 'Main' method suitable for an entry point?, which led me to believe that it wasn't actually including all of the source code. I had to then specify "include": ["**/*.cs"] for it to build correctly. With that it builds but then I also get a warning CS2002: Source file 'obj\Debug\net451\dotnet-compile.assemblyinfo.cs' specified multiple times. Is this expected?

[ajaybhargavb]

@smbecker, this issue was because the defaults weren't used. This was fixed in https://github.com/dotnet/cli/issues/2819. Updating to the latest cli should fix this problem.

[smbecker]

awesome, thanks

[sandorfr]

Is there a specific discussion thread regarding the announcement about the new unified xproj/project.json and csproj. There is a lot of comments regarding this and I might be sane to consult with the community before moving forward.

I quite like the new project.json format and I assume I'm not the only one. I'm very concerned about the msbuild comeback, unless you have some "Build core 1.0" plans and will provide a modern xsln, xproj solution with an efficient DSL instead of what msbuild currently is.

[nmocruz]

@Alxandr to enable the use of portable PDBs I added "debugType" to "buildOptions" and the debug is working ok now.

[ajaybhargavb]

Is there a specific discussion thread regarding the announcement about the new unified xproj/project.json and csproj

cc' @davidfowl @DamianEdwards @Eilon

[DamianEdwards]

@sandorfr not as yet. We plan to provide further information on this in the near future as we get closer to actually doing that work (it's slated for after RTM of the runtime, i.e. after June).

[simonech]

So, basically, RTM will ship with project.json? and later it will change?

[sandorfr]

TLDR: I love project.json for it simplicity and efficiency. Msbuild is a cryptic old fashioned xml based build system and it broke my heart to many times. Support is useful but should be opt-in. You did great with project.json, please keep something as simple as this :).

@DamianEdwards I just watched the QnA of the last community standup, and you got me even more worried :( than I was about this news. Maybe I miss some important points that lead to this decision, and this is why I'm asking a discussion thread. If you expose the core reasons (the why not the how) behind this move, the community (including me) will stop complaining or will come up with a better approach proposal.

With the current project.json/xproj approach we have the following advantages :

• slick .net build story without the need of an additional old school build system (a.k.a. msbuild)
• very simple learning curve for the newcomers and welcome similarity with npm
• simple & unique xplat file format
• dead simple nuget package generation story
• easy to edit with any text editor (no need for an IDE)

It has some drawbacks one is json itself which does not support comments and trailing comma on arrays (but project.yaml format could solve both issues)

If we switch to an msbuild file format :

• build targets coming from somewhere else on the disk
• cryptic msbuild syntax (like this kind of uglyness : http://stackoverflow.com/questions/2747081/how-do-you-include-additional-files-using-vs2010-web-deployment-packages )
• xml based verbose format
• unload project before editing in visual studio (because msbuild support in visual studio is actually terrible)
• what about the development and build story on mac and Ubuntu ?

I definitely understand that Microsoft and some of its customers have built great build pipelines around msbuild and that .net core must play nicely with msbuild. On the other hand, I don't think creating a tight link between msbuild and .net core is mandatory nor the way to go. The out of the box story should remain as dead simple as it is with RC2 today and additional development and build tools like msbuild, vs code, vs 15, Jetbrains Riders should be opt-ins on top of it.

[MaximRouiller]

I also disagree with the move.

I get that other teams want to keep their csproj but for me, it's a step backward. xproj was sold to us as being "just required by Visual Studio for tooling support". And now we're moving back to csproj?

How are we going to handle dependency now? https://github.com/aspnet/Home/issues/1433

How are we going to handle targets? Supporting csproj means integrating targets. How is that going to integrate?

[conniey]

Does the current version of the .NET CLI understand these changes? I have some compiler directives being defined in my project.json but it does not seem to be compiling with those defines when I run dotnet build?

{
  "buildOptions": {
    "define": [ "ICU_VER_56" ],
    "compile": {
      "exclude": [ "Properties/*.cs" ]
    }
  }
}

[andrebaltieri]

We are running the RC1, going to RC2 and thinking about keep or change one of the main files of the Core app?

I strongly agree with @sandorfr. Nowadays a lot of people are familiar with NPM, json files and project.json.

+1 to keep project.json!

[gustavoferrazfontes]

Why do change this now? keep with project.json

[justinhhorner]

+1 for keeping project.json

[alexbocharov]

I think you need to unambiguously leave project.json. Xml is a bad idea

[yanjustino]

keeping projecto.json, please!

[alexsandro-xpt]

Keep project.json, xml .csproj is really bad, xml is inhuman, is not friendly, is not editable without a tool, json is more friendly, readable by default by javascript.

And about MSBuild, it's should upgraded to late.

Do not break the ASP.net revolution.

[nfplee]

+1 for keeping project.json

[alexbocharov]

More informations https://blogs.msdn.microsoft.com/webdev/2016/05/11/notes-from-the-asp-net-community-standup-may-10-2016/

[jedielson]

+1 for keeping project.json

[fabiodomingues]

+1 for keeping project.json

[supercoja]

Keep project.json

[rhires]

Actually, keep project.json. It's like getting a new toy and then being told that old toy you were playing with is better, you know, because the other kids have the old toy. And so you'll have to give up the new toy. How is this better again? Why were there no announcements for "Breaking changes"? Don't want to alert the community? This is a very frustrating and unwelcome change and is not actually better.

[MaximRouiller]

@rhires Because when they announced it, it was pretty much as new to them as it was to us.

[rsbavaresco]

This announcement itself is a great motivation to keep project.json.

It is so easy and comfortable to work with.

[RehanSaeed]

As I discuss here, we basically know nothing, we need to wait for the team to come up with more specifics. A major thing that is unknown that I have not seen much discussion on is whether csproj will now also compile to nupkg's. We're sitting tight for the news.

[halter73]

The runtimeOptions section of this announcement is now out of date. To see the current format, look here: https://github.com/dotnet/cli/blob/v1.0.0-rc2/Documentation/specs/runtime-configuration-file.md#file-format

[feliperochadev]

+1 for keeping project.json please team hear the community!

[mdmoura]

+2000 for keeping project.json. That is one of the nice features in ASP.NET Core. Please, do not go back to MSBuild or XML configuration files ...

[MaximRouiller]

@mdmoura I don't think they'll be able to meet a deadline of "end of June" if they are to transition all .NET projects and Xamarin to a new project.json format. Just in terms of tooling, it would be a major endeavor that could take years to complete and get everyone off of the MSBUILD wagon.

My view of this is that it's a "necessary evil" that we'll need to live with for the time being. I'm hoping that the future will be different than MSBUILD.

Just my 2 cents.

[DavidObando]

@ajaybhargavb I have a minor observation. In the post we have this example:

{
  "runtimeOptions": {
    "gcServer": false,
    "gcConcurrent": true
  }
}

Could we change this to say "gcServer": true? Code snippets like that end up being what people put in their projects, and if I were to give people a default, I'd argue servergc is preferable.

[Eilon]

@DavidObando good suggestion, I made the change.

[halter73]

@DavidObando @Eilon In a comment above, I posted a link to https://github.com/dotnet/cli/blob/v1.0.0-rc2/Documentation/specs/runtime-configuration-file.md#file-format which I found has a more up-to-date format for "runtimeOptions". As of RC2, the "runtimeOptions" section of .runtimeconfig.json is copied verbatim (with the exception of the target parameter) from the same section in project.json.

At the time, I didn't update the announcement itself, because I figured that was supposed to reflect the state of things at the point in time the announcement was made. But since we're accounting for people copying code snippets from the announcements, I decided to update the announcement now to show the current format. E.g:

"runtimeOptions": {
    "configProperties": {
        "System.GC.Server": true,
        "System.GC.Concurrent": true
    }
}

[Eilon]

@halter73 ah sure, that's fine.

[dazinator]

Just trying to migrate an rc1 project.json to rc2 and wanted to check something.

In RC1 I have this in my project.json files:

{
"exclude":  ["wwwroot","node_modules","shadowed","artifacts", "modules" ],
}

According to the docs, this ensures those paths are excluded from: CompileList, PreprocessList, SharedList, ResourceList, and ContentList.

What does this look like for an equivalent RC2 project.json?

My guess is:

{
  "buildOptions": {  
      "compile": {      
          "exclude":  ["wwwroot","node_modules","shadowed","artifacts", "modules" ]
       },
      "embed": {
          "exclude":  ["wwwroot","node_modules","shadowed","artifacts", "modules" ] 
      },
      "copyToOutput": {      
        "exclude":  ["wwwroot","node_modules","shadowed","artifacts", "modules" ]
      }
  }
}

[ajaybhargavb]

@dazinator, the equivalent in RC2 would be

{
  "buildOptions": {  
      "compile": {      
          "exclude":  ["wwwroot","node_modules","shadowed","artifacts", "modules" ]
       },
      "embed": {
          "exclude":  ["wwwroot","node_modules","shadowed","artifacts", "modules" ] 
      }
  }
}

copyToOutput and publish don't include anything by default.

[dazinator]

@ajaybhargavb - thank you.

[lgreenlee]

Thanks for the great documentation on these settings. One question, when will the project.json file be phased out, and what will VS Code users need to do to support the transition?

[guardrex]

@lgreenlee They haven't announced an ETA. We only know "post RTM." There is some additional info here: https://github.com/dotnet/core-docs/pull/550. You can see planning issues open now: https://github.com/dotnet/cli/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20msbuild. You can see some WIP here: https://github.com/dotnet/cli/pull/3680.

AFAICT dotnet restore/build/pack/publish will get under-the-hood changes to work with MSBuild. Therefore, the change will be somewhat or mostly transparent in terms of using CLI commands to get things done. They have stated that tooling will help convert project.json into .csproj.

[guardrex]

@lgreenlee Oh ... and just for fun ... check this out ... I must have WAY too much free time on my hands. :smile: https://github.com/GuardRex/GuardRex.JsonToCsprojConverter

[lgreenlee]

@GuardRex That is great! I'll star that for future use. I just put this together today: https://github.com/42north/ubuntu-xenial-dcp-sample-app which is why I was asking.

[FransBouma]

(preview 2, RTM)

"buildOptions": {
    "xmlDoc": true,
}

Gives _foldername_.xml, not _name_.xml, so the assembly is called e.g. MyOrg.Tools.SomeLib.dll, but as it is located in 'src' folder, the xml file is called src.xml, while it should be called MyOrg.Tools.SomeLib.xml

[guardrex]

@FransBouma It honors buildOptions > outputName. I think if you set that to MyOrg.Tools.SomeLib it will work ... I think. :smile:

I guess csproj offers finer control, including the path. I just saw this ...

<DocumentationFile>$(MSBuildProjectDirectory)\$(OutputPath)$(MSBuildProjectName).XML</DocumentationFile>

[FransBouma]

'outputName' indeed works. Strange as the compiler honors 'name' for assembly name, but outputName is only honored for xmloutput. Oh well...

Btw, couldn't find docs about this.

[guardrex]

Yikes! ... yeah ... that's a sad :cry: story that will likely not be addressed due to the move to csproj. The docs are either incomplete or out-of-date. We would expect to see outputName at ...

http://json.schemastore.org/project
https://docs.nuget.org/consume/projectjson-format
https://docs.microsoft.com/en-us/dotnet/articles/core/tools/project-json

... but it only even appears in the first one, and then we find no description for it.

Presumably for csproj, we'll have AssemblyName and DocumentationFile to cover naming, and it seems that the WIP on that transition is going well and fast. :+1:

[Joel-S-Black]

I'm having problems with publishOptions. I'm trying to include a file "Serilog.FullNetFx.dll" in my publish output along with the rest of the DLLs. When I do this:

"publishOptions": {
"include": [
"wwwroot",
"Views",
"Areas/**/Views",
"appsettings.json",
"web.config"
],
"includeFiles": "./bin/Debug/net46/win7-x64/Serilog.FullNetFx.dll"
},

The file is published, but to a new "..binDebug\net46\win7-x64" location. I need it to be published to ".." Is there a way to specify a different source path from destination path? When I have tried this:

"includeFiles": "./Serilog.FullNetFx.dll" , I get a file not found error on publish. I looked through this documentation: https://github.com/aspnet/Announcements/issues/175#include-structure and haven't found any clarification as to how this should be used.

[Eilon]

@jllblk I recommend asking on https://github.com/dotnet/cli/issues/, which is where the publishOptions feature is implemented. You might also want to mention why you need to explicitly include that DLL - those are normally included only when needed by the build system and are rarely, if ever, explicitly published.

[moozzyk]

@jllblk - look at "mappings"

[aspnet-hello]

This issue is being closed because it has not been updated in 3 months.

We apologize if this causes any inconvenience. We ask that if you are still encountering this issue, please log a new issue with updated information and we will investigate.