At minute to twelve, MSBuild makes a comeback
-
Microsoft has been pushing nuget oriented
project.json
for years now, replacing those awful xml configuration files. Then suddenly, weeks before the expected .NET core release, they announce they are reverting back to MSBuild.https://wildermuth.com/2016/05/12/The-Future-of-project-json-in-ASP-NET-Core
TL;DR;
Microsoft has decided after the RTM of the ASP.NET Core framework to phase out project.json and use MSBuild for build data. They’ve not decided whether to keep the NuGet dependencies in a pared down project.json (maybe renamed to nuget.json) or whether to just allow for a command-line action like “nuget install dependency --save” to mirror what other package managers do.The github peanut gallery has predictably freaked out.
I just don't get why all the things has been suffixed with "core" to indicate it's a brand new thing if the intention is also to carry the baggage forward like msbuild.
The process has been too painful for more than two years but lots of people were OK because all of new additions and improvements were aligning the ecosystem with other ecosystems and all of them were changes for good reasons. However, suddenly, dark matter enterprise developers started giving feedback behind the closed doors and we are seeing lots of baggage to be carried forward.
I'm seeing things negatively because this is a massive, late breaking change to a fundamental part of the .NET Core story, a part that was communicated to us as being core to the future, and we (perhaps stupidly) took them at their word, and have built a CD/CI pipeline based on this tech that is now utterly worthless. I'm also seeing it negatively because in a full day of asking for details on the decision making there's been utter radio silence.
I know that project.json has accumulated complexity. I 100% agree on that point. Was the solution to merge back to csproj? I told people before, I'm completely behind Microsoft for making things right rather than shipping in a hurry. The move to csproj looks rushed.
Why do this after RC2? Where did this come from? Does the Xamarin acquisition had anything to do in this? Was it the dotnet-cli integration? Was it a big client? Who knows...
I could explain to the masses that RC1 -> RC2 was for the best. Unified with the dotnet cli. But the project.json change? I have nothing to say to explain it. Just that I don't know. People are confused and I have no compeling arguments for them.
Personally, I liked project.json the few times I worked with it. At this late hour, weeks before the launching of .net core, this switch feels rushed and ill considered.
On the other hand, MS might have good reasons too. Maybe json isn't versatile enough to support everything they need for apps outside of asp.net. Also, how often do people even tinker with project configuration files in the first place?
-
The JSON files had one significant drawback: no comments. While it'd be okay to keep that for the NuGet configuration, I think, not being able to comment the Web.config-equivalent info in project.json was a pain.
-
@atimson It's not that uncommon to see json parsers with support for comments. It may not be in the spec but it's common in the wild.
-
@atimson I think their special parser supports the comments. You often see that in projects that use json.
Personally, I prefer yaml, which is a superset of json, even if it doesn't look like it.
-
@cartman82 said in At minute to twelve, MSBuild makes a comeback:
a superset of json
GIS, you have some interesting images available for “superset”…
http://muscles.gr/wp-content/uploads/2014/05/10259853_10152052131966027_6781975380499429290_n1.jpg
-
SUPAAAARSET
-
OH FFS Microsoft, they have completely balls up ASP.NET 5 / Core / Whatever they are calling it now.
-
@dkf
You just made this thread worthwhile
-
@cartman82 said in At minute to twelve, MSBuild makes a comeback:
Personally, I prefer yaml
^ This. YAML is perfect for this kind of stuff.
-
@asdf Rust's TOML is also nice and a bit simpler than YAML. JSON kinda sucks for configuration files, and please let's not talk about XML configuration files at all.
-
There's nothing wrong with the existing XML format. Fixing what's not broken because JSON is "more trendy" is retarded.
That said, leaving decisions like this to the last second is also retarded. But hey, they're all open source-y now. This is the kind of shit that happens.
-
@blakeyrat No there is not anything wrong with the current XML format, however csproj files are a very VS only view of the world.
-
@lucas1 There's nothing in them specific to Visual Studio.
-
@blakeyrat So who uses them for anything else?
-
@dkf said in At minute to twelve, MSBuild makes a comeback:
So who uses them for anything else?
Uh, MSBuild? To build projects?
Either you're an idiot, or I don't understand your question.
-
@blakeyrat *sigh*
Who uses them apart from people deep in the build ecosystem that includes both MSBuild and Visual Studio?
-
@dkf what does Mono use?
-
@dkf said in At minute to twelve, MSBuild makes a comeback:
Who uses them apart from people deep in the build ecosystem that includes both MSBuild and Visual Studio?
Who cares and why is that relevant?
Who uses NPM apart from people deep in the build ecosystem that includes Node.JS? Well. Nobody. It's kind of for Node.JS. That's kind of... the entire purpose of it.
The only "problem" with MSBuild's XML-based formats is that they were designed back in 2000-- that is, they're old and use technologies that have since become less relevant. But that's not an actual problem, that's just hipsters hating to use anything older than their cellphones to do development work with.
-
@Jaloopa said in At minute to twelve, MSBuild makes a comeback:
what does Mono use?
You're asking the guy who sincerely can't answer that question? For all I know, they use a team of highly trained gnomes riding on performing guinea pigs.
-
@blakeyrat said in At minute to twelve, MSBuild makes a comeback:
The only "problem" with MSBuild's XML-based formats is that they were designed back in 2000-- that is, they're old and use technologies that have since become less relevant. But that's not an actual problem, that's just hipsters hating to use anything older than their cellphones to do development work with.
These are the same ones who also won't move on from 1970s technologies, right?
-
@boomzilla yeah but they develop for them on their phones. Possibly through a bash shell on android
-
@blakeyrat I've just pulled this from a random csproj file.
<PropertyGroup> <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion> <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath> </PropertyGroup> <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" /> <Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" /> <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" /> <Target Name="MvcBuildViews" AfterTargets="AfterBuild" Condition="'$(MvcBuildViews)'=='true'"> <AspNetCompiler VirtualPath="temp" PhysicalPath="$(WebProjectOutputDir)" /> </Target> <ProjectExtensions> <VisualStudio> <FlavorProperties GUID="{349c5851-65df-11da-9384-00065b846f21}"> <WebProjectProperties> <UseIIS>True</UseIIS> <AutoAssignPort>True</AutoAssignPort> <DevelopmentServerPort>51356</DevelopmentServerPort> <DevelopmentServerVPath>/</DevelopmentServerVPath> <IISUrl>http://localhost:50920/</IISUrl> <NTLMAuthentication>False</NTLMAuthentication> <UseCustomServer>False</UseCustomServer> <CustomServerUrl> </CustomServerUrl> <SaveServerSettingsInUserFile>False</SaveServerSettingsInUserFile> </WebProjectProperties> </FlavorProperties> </VisualStudio> </ProjectExtensions>
Also the way Visual Studio adds and removed solution items to the csproj file can be a PITA to merge sometimes and even Microsoft MVP hate it.
There was a whole bunch of actually good reasons why they wanted to get rid of csproj which I have ran into. I am having problems finding the link for a comprehensive explanation I read several months ago.
-
@lucas1 said in At minute to twelve, MSBuild makes a comeback:
I've just pulled this from a random csproj file.
Congratulations?
Are you attempting to make some kind of point, or just filling-up the text field?
-
@blakeyrat said in At minute to twelve, MSBuild makes a comeback:
There's nothing in them specific to Visual Studio.
-
@blakeyrat said in At minute to twelve, MSBuild makes a comeback:
The only "problem" with MSBuild's XML-based formats is that they were designed back in 2000
Actually, no. They suck goatballs because they can't merge worth a fuck (particularly when adding projects or changing framework versions of projects). Most likely it was found that the JSON format performed equally poorly, so why bother breaking everybody's toolchains?
-
@blakeyrat said in At minute to twelve, MSBuild makes a comeback:
There's nothing wrong with the existing XML format. Fixing what's not broken because JSON is "more trendy" is retarded.
Luddite. OnionBelt.xml
-
@Jaloopa said in At minute to twelve, MSBuild makes a comeback:
@dkf what does Mono use?
From my limited experience on Mono project, it's also MSBuild (XBuild is their port to MSBuild so that they can build project based on .SLN files on Linux).
AFAIK, MonoDevelop/SharpDevelop also consume .SLN + .CSPROJ files.
-
@lucas1 said in At minute to twelve, MSBuild makes a comeback:
Also the way Visual Studio adds and removed solution items to the csproj file can be a PITA to merge sometimes and even Microsoft MVP hate it.
There was a whole bunch of actually good reasons why they wanted to get rid of csproj which I have ran into. I am having problems finding the link for a comprehensive explanation I read several months ago.
To be fair, even if it's in JSON, the program that saves the file can still remove items that it don't recognize at will.
The problem is caused by the IDE overwrites the project file by file freshing generated using the internal data only instead of updating the file. It can happen on any file format. With project files in XML format, at least you can insert back the removed settings back using XSLT templates. By changing to use JSON format that means I would have to search for another tool to do the same thing.
-
@cheong said in At minute to twelve, MSBuild makes a comeback:
With project files in XML format, at least you can insert back the removed settings back using XSLT templates.
I am fucking horrified at what you must be doing to even consider editing those god damned files, nevermind running transforms against them.
-
@cheong said in At minute to twelve, MSBuild makes a comeback:
The problem is caused by the IDE overwrites the project file by file freshing generated using the internal data only instead of updating the file.
Puts working with a Maven POM in perspective, I guess. (That's XML build configuration done
rightless wrong, given how less painful it seems to me.)
-
@cheong With the project.json it was going to be the other way around e.g. instead of adding files into the IDE you have to specifically state the files are not to be included
-
You said this:
@blakeyrat said in At minute to twelve, MSBuild makes a comeback:
@lucas1 There's nothing in them specific to Visual Studio.
There is Visual Studio specific bits and pieces in that snippet from my csproj file. The elements can be identified by the fact that they have the words "Visual" and "Studio" in the elements.
-
@dkf said in At minute to twelve, MSBuild makes a comeback:
@cheong said in At minute to twelve, MSBuild makes a comeback:
The problem is caused by the IDE overwrites the project file by file freshing generated using the internal data only instead of updating the file.
Puts working with a Maven POM in perspective, I guess. (That's XML build configuration done
rightless wrong, given how less painful it seems to me.)Maven POM files are generally created manually by one of the developers. As opposed to MSBuild files, which are usually generated by Visual Studio.
-
Just remembered these in vbproj and csproj files:
Visual Studio if it doesn't know the project type GUID it won't load the project in a solution. I've ran into this personally when trying to load a VS2010 project in 2013. MVC2 templates aren't included in VS2013, so the web project wouldn't load up as it was a MVC2 project. I've had to manually upgrade the project to MVC3 in VS2010, change the proj type guids and then try opening again in 2013.
EDIT: This can cause you some headaches when merging. Also I would like to avoid having to upgrade libraries just so VS will load the solution.
-
@lucas1 said in At minute to twelve, MSBuild makes a comeback:
You said this:
Don't bother. Every time he's proven wrong on something, he mutes the topic and pretends the conversation never happened. And then he denies he does this.
-
@Gąska I thought as much.
-
@powerlord said in At minute to twelve, MSBuild makes a comeback:
Maven POM files are generally created manually by one of the developers.
My IDE can generate them. It doesn't do everything, but it does most of the normal stuff (e.g., managing dependencies and so on).
-
@cheong said in At minute to twelve, MSBuild makes a comeback:
at least you can insert back the removed settings back using XSLT templates
This is a bit offtopic, but is XSLT really easier to use than just writing a quick script in your favourite language that uses the DOM library to insert elements? That just seems weird to me.
-
@anonymous234 No. XSLT is evil.
-
@powerlord said in At minute to twelve, MSBuild makes a comeback:
Maven POM files are generally created manually by one of the developers.
Eclipse generates them. I assume some of the other Java IDEs do too.
-
@lucas1 I believe what was meant when saying "specific to Visual Studio" is that standards wise there's nothing specific to VS.
The elements could be called "JuJuBerryFartBlaster" and that doesn't mean it's specific to the JuJu Berry or Fart Blasters... it's just a name of an element. As long as it follows XML standards, it can be parsed by anyone who follows that standard. The naming is arbitrary.
Hence why MonoDevelop and XBuild can handle VS and MSBuild config files.
-
@anonymous234 said in At minute to twelve, MSBuild makes a comeback:
This is a bit offtopic, but is XSLT really easier to use than just writing a quick script in your favourite language that uses the DOM library to insert elements? That just seems weird to me.
As long as you have a template at handy place for you to modify from.
It's as simple as copying the xsl:template tag, change the "match' attribute to the path you want to add element to, and replace the inner XML with the tags you want to add.
The most important fact is that, for those who need that, they've already written that.
And then if you use MSBuild, there is already build-in functionality for you to modify the .csproj file as a build step.
-
@loopback0 said in At minute to twelve, MSBuild makes a comeback:
@powerlord said in At minute to twelve, MSBuild makes a comeback:
Maven POM files are generally created manually by one of the developers.
Eclipse generates them. I assume some of the other Java IDEs do too.
It has a wizard to generate POM files but it hardly ever changes those POMs, instead you're editing a second
.project
file. This results in schizophrenic situations unless you remember to "Update Maven projects " to reset the Eclipse project for each POM update.However, that's entirely different from the Visual Studio situation where everyone is working directly on the project files and where some project editors might choose to drop unrecognized fields.
-
@lucas1 said in At minute to twelve, MSBuild makes a comeback:
The elements can be identified by the fact that they have the words "Visual" and "Studio" in the elements.
You know, the conversation would go a lot quicker if you would just make your point in the first place, instead of posting trivia then waiting all day before you come back and explain what the fuck you were trying to communicate with it.
Yes, those are unfortunate tag names. The actual data inside those tags is not specific to Visual Studio. Saying, "hey when you debug this project, here's which web server to use" applies to all IDEs.
@Gąska said in At minute to twelve, MSBuild makes a comeback:
Don't bother. Every time he's proven wrong on something, he mutes the topic and pretends the conversation never happened.
Except I'm not wrong, and there's no "mute" on this forum.
@anonymous234 said in At minute to twelve, MSBuild makes a comeback:
This is a bit offtopic, but is XSLT really easier to use than just writing a quick script in your favourite language that uses the DOM library to insert elements? That just seems weird to me.
Visual Studio has a built-in feature to transform XMLs, we use it for the web.config file (so we have a single template one, and a lot of tiny "here's what you change to build this site for this client" ones). It's pretty painless.
I'm not sure why you'd use that feature on a .csproj file or what you'd gain from it, but.
-
@lordofduct said in At minute to twelve, MSBuild makes a comeback:
I believe what was meant when saying "specific to Visual Studio" is that standards wise there's nothing specific to VS.
The elements could be called "JuJuBerryFartBlaster" and that doesn't mean it's specific to the JuJu Berry or Fart Blasters... it's just a name of an element. As long as it follows XML standards, it can be parsed by anyone who follows that standard. The naming is arbitrary.
Hence why MonoDevelop and XBuild can handle VS and MSBuild config files.Yeah, but that is like saying there is nothing VS specific in there only because the config files do not intentionally try to implant viruses in to other IDEs. Or that there is nothing VS specific in them because they are not required to have contained in them:
del "C:\Program Files\Jetbrains/*
del "C:\Program Files\EclipseEtc.
-
@blakeyrat said in At minute to twelve, MSBuild makes a comeback:
Except I'm not wrong
You could not be any more wrong if you tried. Simply shutting your ears and pretending as though you are not does not change the reality.
-
@Polygeekery Oh, well, you provide a compelling argument that will surely shift my opinion on the matter.
-
@blakeyrat Yeah, I learned a long time ago that when you dig your toes in on a subject and do not want to admit you are wrong, that there is nothing I can do to change your mind so instead I just ridicule you. It is more fun, and more productive. What you said was asinine and incorrect.
@blakeyrat said in At minute to twelve, MSBuild makes a comeback:
There's nothing in them specific to Visual Studio.
Then we show you the many things in them that is specific to Visual Studio and you pretend like there isn't. So what is your fucking point?
-
@Polygeekery If you just want to declare everything I say is wrong, fine, whatever. But maybe just do it silently instead of just following me around to every topic and calling me an idiot in a FrostCat-esque way? It'd save both of us time. Plus I already have FrostCat to do that.
@Polygeekery said in At minute to twelve, MSBuild makes a comeback:
Then we show you the many things in them that is specific to Visual Studio and you pretend like there isn't.
That never happened, but ok. We're in the Intercourse Fantasy World, where reality has no grasp.
-
@blakeyrat said in At minute to twelve, MSBuild makes a comeback:
If you just want to declare everything I say is wrong, fine, whatever. But maybe just do it silently instead of just following me around to every topic and calling me an idiot in a FrostCat-esque way? It'd save both of us time. Plus I already have FrostCat to do that.
No, I just call you on your bullshit. Like when you say:
@blakeyrat said in At minute to twelve, MSBuild makes a comeback:
There's nothing in them specific to Visual Studio.
How much more specific to Visual Studio can you get than declaring which version of Visual Studio to use when editing the project files? How is that not:
@blakeyrat said in At minute to twelve, MSBuild makes a comeback:
specific to Visual Studio.
Explain that bit of logic to me.