New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discussion: Updates to project.json schema #1418
Comments
Where should |
Also, does this affect the |
No. |
@ajaybhargavb Is I added ... "copyToOutput": {
"include": [ "Views", "wwwroot", "Logs" ]
} ... to |
Is it possible to some type of global version numbering? When using DNX it was posible to use the |
@Tasteful It's been backlogged ... https://github.com/dotnet/cli/issues/551 and https://github.com/dotnet/cli/issues/549 |
What about |
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 |
@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. |
awesome, thanks |
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. |
@Alxandr to enable the use of portable PDBs I added "debugType" to "buildOptions" and the debug is working ok now. |
|
@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). |
So, basically, RTM will ship with project.json? and later it will change? |
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 :
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 :
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. |
I also disagree with the move. I get that other teams want to keep their csproj but for me, it's a step backward. How are we going to handle dependency now? #1433 How are we going to handle targets? Supporting csproj means integrating targets. How is that going to integrate? |
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 {
"buildOptions": {
"define": [ "ICU_VER_56" ],
"compile": {
"exclude": [ "Properties/*.cs" ]
}
}
} |
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! |
Why do change this now? keep with project.json |
+1 for keeping project.json |
I think you need to unambiguously leave |
keeping projecto.json, please! |
Keep And about MSBuild, it's should upgraded to late. Do not break the ASP.net revolution. |
+1 for keeping project.json |
+1 for keeping project.json |
+1 for keeping project.json please team hear the community! |
+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 ... |
@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 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. |
@ajaybhargavb I have a minor observation. In the post we have this example:
Could we change this to say |
@DavidObando good suggestion, I made the change. |
@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 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:
|
@halter73 ah sure, that's fine. |
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:
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:
|
@dazinator, the equivalent in RC2 would be {
"buildOptions": {
"compile": {
"exclude": ["wwwroot","node_modules","shadowed","artifacts", "modules" ]
},
"embed": {
"exclude": ["wwwroot","node_modules","shadowed","artifacts", "modules" ]
}
}
}
|
@ajaybhargavb - thank you. |
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? |
@lgreenlee They haven't announced an ETA. We only know "post RTM." There is some additional info here: dotnet/docs#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: dotnet/cli#3680. AFAICT |
@lgreenlee Oh ... and just for fun ... check this out ... I must have WAY too much free time on my hands. 😄 https://github.com/GuardRex/GuardRex.JsonToCsprojConverter |
@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. |
(preview 2, RTM)
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 |
@FransBouma It honors I guess <DocumentationFile>$(MSBuildProjectDirectory)\$(OutputPath)$(MSBuildProjectName).XML</DocumentationFile> |
'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. |
Yikes! ... yeah ... that's a sad 😢 story that will likely not be addressed due to the move to http://json.schemastore.org/project ... but it only even appears in the first one, and then we find no description for it. Presumably for |
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": { The file is published, but to a new "..\bin\Debug\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: aspnet/Announcements#175 (comment) and haven't found any clarification as to how this should be used. |
@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. |
@jllblk - look at "mappings" |
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. |
Don't install 2.0 on linux-musl
Discussion for aspnet/Announcements#175
The text was updated successfully, but these errors were encountered: