Please Consider Improving Project Format and Structure (Serialized POCO/Format Agnostic) #613

Open
Mike-EEE opened this Issue May 12, 2016 · 169 comments

Comments

Projects
None yet
@Mike-EEE

Going to try this again, but hopefully with a better defined ask. The request is not to support a particular format, but to improve the MSBuild system overall so that it can support any format, while also making it more accessible/discoverable by tooling and (possible) designers.

Based on the current climate of .NET Core having its project.json merged back into MSBuild, this topic might get a little more interest conversation. Also, the Roslyn team is sending developers your way, so, there's that. :)

Use Case: Developers REALLY like their file formats!

Problem(s):

  1. MSBuild format is rooted in an arbitrary, not well-defined/known schema (difficult to explore and discover).
  2. MSBuild project structure can only be defined/edited in XML.
  3. MSFT development ecosystem (for better or for worse) is now comprised of two camps: web application developers and native application developers each has their own way of doing things and neither really likes the approach of the other.

Suggestions:

  1. Create a well-defined, well-known .NET object model that defines the Project Model (Project API). Visual Studio then loads (and saves) these as POCOs on disk. In this design, there are no arbitrary schemas or data files, but 100% serialized POCOs which are read and saved to disk. Another issue on Roslyn's board goes into more detail around this.
  2. Adopt a "Bring Your Own Serializer" strategy. Adding a new format/type is as simple as installing a Visual Studio extension (or even auto-detected and installed for you upon detection/initial file load). To start with, JSON5 and XML should be supported out of the box, but developers should be able to bring on any format they wish, such as Xaml, Yaml, etc.
  3. Allow (optional) naming extensions for projects to help identify stored format. Examples:
  • MyProject.csproj.json5 <-- C# Project serialized as JSON5
  • MyProject.vbproj.xml <-- VB.NET Project serialized as XML
  • MyProject.fsproj.xaml <-- F# Project serialized as XAML (OH YES I WENT THERE!!!)

Those are off the top of my head to get the conversation started. All of these are open to feedback of course and I would love to hear the thoughts of developers around this. Thank you for any consideration and/or support!

@SolalPirelli

This comment has been minimized.

Show comment
Hide comment
@SolalPirelli

SolalPirelli May 12, 2016

I think you're vastly over-estimating the demand for different file formats. Who really cares about XML vs JSON? And more importantly, are there enough people who care enough to justify adding complexity to the entire build system?
The current problems with MSBuild files are historical: they're meant to be read/written by VS tooling exclusively (and not humans), they don't support packages as first-class citizens, etc. . XML is not a problem.

I think you're vastly over-estimating the demand for different file formats. Who really cares about XML vs JSON? And more importantly, are there enough people who care enough to justify adding complexity to the entire build system?
The current problems with MSBuild files are historical: they're meant to be read/written by VS tooling exclusively (and not humans), they don't support packages as first-class citizens, etc. . XML is not a problem.

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE May 12, 2016

Thanks for your input @SolalPirelli. I am not sure what you mean by adding complexity. The solutions/goal is to reduce complexity while also satisfying developer (and organizational) preferences. Even if the tooling is meant to be used by VS/IDE exclusively, that does not mean that humans don't get their proverbial hands dirty with it, and they do all the time. The process for doing as such is very clumsy and awkward (which I believe you allude to via "historical").

I would also challenge you on demand for JSON vs. XML. What forums/tweets have you been reading? 😄

Thanks for your input @SolalPirelli. I am not sure what you mean by adding complexity. The solutions/goal is to reduce complexity while also satisfying developer (and organizational) preferences. Even if the tooling is meant to be used by VS/IDE exclusively, that does not mean that humans don't get their proverbial hands dirty with it, and they do all the time. The process for doing as such is very clumsy and awkward (which I believe you allude to via "historical").

I would also challenge you on demand for JSON vs. XML. What forums/tweets have you been reading? 😄

@SolalPirelli

This comment has been minimized.

Show comment
Hide comment
@SolalPirelli

SolalPirelli May 12, 2016

I am not sure what you mean by adding complexity.

Adding support for multiple file formats necessarily increases complexity. It means adding a public API that third-party providers will use, which will definitely cause headaches when new items are added and it turns out providers were doing crazy things to enable DSLs.

I would also challenge you on demand for JSON vs. XML. What forums/tweets have you been reading?

If this is to be resolved via forums and tweets, we'll end up writing our config file in Go, JavaScript or Rust.
The exact markup format does not matter, what matters is that the resulting format is editable by both humans and programs, adapted to current needs, and prepared for future evolution. There's nothing in JSON that makes it clearly better than XML in that regard. If anything, JSON is worse because it lacks comments.

I am not sure what you mean by adding complexity.

Adding support for multiple file formats necessarily increases complexity. It means adding a public API that third-party providers will use, which will definitely cause headaches when new items are added and it turns out providers were doing crazy things to enable DSLs.

I would also challenge you on demand for JSON vs. XML. What forums/tweets have you been reading?

If this is to be resolved via forums and tweets, we'll end up writing our config file in Go, JavaScript or Rust.
The exact markup format does not matter, what matters is that the resulting format is editable by both humans and programs, adapted to current needs, and prepared for future evolution. There's nothing in JSON that makes it clearly better than XML in that regard. If anything, JSON is worse because it lacks comments.

@aolszowka

This comment has been minimized.

Show comment
Hide comment
@aolszowka

aolszowka May 12, 2016

I would also challenge you on demand for JSON vs. XML. What forums/tweets have you been reading?

I'll challenge you right back; never in a professional environment, by someone who I would consider a professional developer (or Build Master), would I say I've heard a cry for a switch to a JSON based MSBuild.

I will agree with regards to documentation and ask that the current XML format be better documented; but as far as a switch to JSON I see little to no technical gains. Why not take those resources that would be wasted on such a system and instead put them towards improving the MSDN docs?

As per Raymond Chen every feature starts out at -100; what are the gains that get us to Positive 100?

I would also challenge you on demand for JSON vs. XML. What forums/tweets have you been reading?

I'll challenge you right back; never in a professional environment, by someone who I would consider a professional developer (or Build Master), would I say I've heard a cry for a switch to a JSON based MSBuild.

I will agree with regards to documentation and ask that the current XML format be better documented; but as far as a switch to JSON I see little to no technical gains. Why not take those resources that would be wasted on such a system and instead put them towards improving the MSDN docs?

As per Raymond Chen every feature starts out at -100; what are the gains that get us to Positive 100?

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE May 12, 2016

If this is to be resolved via forums and tweets, we'll end up writing our config file in Go, JavaScript or Rust.If this is to be resolved via forums and tweets, we'll end up writing our config file in Go, JavaScript or Rust.

LOL!!!

I hear you. As for the API. Yes, that is the goal here. To (ultimately) have a well-defined/documented/accessible project API that we all know and have availability to, in case we want to know the file (project) we're actually describing. :)

When you open a .csproj file now... can you in all honesty say you know each and every element within it? The schema is difficult at best to discover and browse. Whereas if we were using a well-known API (.NET POCOs) then this becomes a snap.

If anything, JSON is worse because it lacks comments.

Agreed. But not everyone is agreement with this. And also, I am suggesting JSON5, which allows comments. Finally, the serialization is intended to be an implementation detail, and not supposed to be something that is part of MSBuild, per se. It just has to support it.

If this is to be resolved via forums and tweets, we'll end up writing our config file in Go, JavaScript or Rust.If this is to be resolved via forums and tweets, we'll end up writing our config file in Go, JavaScript or Rust.

LOL!!!

I hear you. As for the API. Yes, that is the goal here. To (ultimately) have a well-defined/documented/accessible project API that we all know and have availability to, in case we want to know the file (project) we're actually describing. :)

When you open a .csproj file now... can you in all honesty say you know each and every element within it? The schema is difficult at best to discover and browse. Whereas if we were using a well-known API (.NET POCOs) then this becomes a snap.

If anything, JSON is worse because it lacks comments.

Agreed. But not everyone is agreement with this. And also, I am suggesting JSON5, which allows comments. Finally, the serialization is intended to be an implementation detail, and not supposed to be something that is part of MSBuild, per se. It just has to support it.

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE May 12, 2016

I'll challenge you right back; never in a professional environment, by someone who I would consider a professional developer (or Build Master), would I say I've heard a cry for a switch to a JSON based MSBuild.

Well dudes... WHERE HAVE YOU BEEN IN MY LIFE FOR THE PAST YEAR?!?! LOL. I guess I have some baaaaaad luck then, because I have been harping against the project.json movement for over a year now and it has seemed to have been an uphill battle, to say the least!

I personally am very much more in the XML camp (I would actually prefer to see Xaml), but I want to consider and be mindful of the developers who have been enjoying the shiny new toy of project.json for the past year.

I'll challenge you right back; never in a professional environment, by someone who I would consider a professional developer (or Build Master), would I say I've heard a cry for a switch to a JSON based MSBuild.

Well dudes... WHERE HAVE YOU BEEN IN MY LIFE FOR THE PAST YEAR?!?! LOL. I guess I have some baaaaaad luck then, because I have been harping against the project.json movement for over a year now and it has seemed to have been an uphill battle, to say the least!

I personally am very much more in the XML camp (I would actually prefer to see Xaml), but I want to consider and be mindful of the developers who have been enjoying the shiny new toy of project.json for the past year.

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE May 12, 2016

And also, I do not want to "switch to JSON" ... but to simply support it as a serialization mechanism. If we're working with well-defined/known POCOs from an API, what matter does it make the format it is serialized/deserialized in?

And also, I do not want to "switch to JSON" ... but to simply support it as a serialization mechanism. If we're working with well-defined/known POCOs from an API, what matter does it make the format it is serialized/deserialized in?

@aolszowka

This comment has been minimized.

Show comment
Hide comment
@aolszowka

aolszowka May 12, 2016

When you open a .csproj file now... can you in all honesty say you know each and every element within it?

Yes; that is what part of being a Build Master and putting on your resume that you speak MSBUILD means. I know the community has had a recent influx of posers from the "DevOps" movement; but there are still the few who actually know what they're doing beyond a drag n' derp interface.

The schema is difficult at best to discover and browse.

This is the primer for anyone coming into MSBuild that needs to start with https://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx Reading Sayed Ibrahim Hashimi's "Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build" should also be required reading for anyone claiming intimate knowledge.

WHERE HAVE YOU BEEN IN MY LIFE FOR THE PAST YEAR?!?!

Monitoring the progress of MSBuild's open sourcing; trying to assist on StackOverflow under the MSBuild Tag (when Sayed isn't beating me to the punch). #JustBuildMasterThings

I want to consider and be mindful of the developers who have been enjoying the shiny new toy of project.json for the past year.

I see no reason why both projects cannot coexist; each project should be allowed to fail or succeed based on its technical merits. Instead of chasing tail lights I personally feel that resources are better spent on improving what we have if there is a clear technical gain. That being said I'm not the Product Owner, nor even a Developer, just a well informed end user.

but to simply support it as a serialization mechanism

Again what is accomplished from this?

aolszowka commented May 12, 2016

When you open a .csproj file now... can you in all honesty say you know each and every element within it?

Yes; that is what part of being a Build Master and putting on your resume that you speak MSBUILD means. I know the community has had a recent influx of posers from the "DevOps" movement; but there are still the few who actually know what they're doing beyond a drag n' derp interface.

The schema is difficult at best to discover and browse.

This is the primer for anyone coming into MSBuild that needs to start with https://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx Reading Sayed Ibrahim Hashimi's "Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build" should also be required reading for anyone claiming intimate knowledge.

WHERE HAVE YOU BEEN IN MY LIFE FOR THE PAST YEAR?!?!

Monitoring the progress of MSBuild's open sourcing; trying to assist on StackOverflow under the MSBuild Tag (when Sayed isn't beating me to the punch). #JustBuildMasterThings

I want to consider and be mindful of the developers who have been enjoying the shiny new toy of project.json for the past year.

I see no reason why both projects cannot coexist; each project should be allowed to fail or succeed based on its technical merits. Instead of chasing tail lights I personally feel that resources are better spent on improving what we have if there is a clear technical gain. That being said I'm not the Product Owner, nor even a Developer, just a well informed end user.

but to simply support it as a serialization mechanism

Again what is accomplished from this?

@SamuelEnglard

This comment has been minimized.

Show comment
Hide comment
@SamuelEnglard

SamuelEnglard May 12, 2016

I personally think what we need is a good way for the two build systems to share data, so that MSBuild can import data from a JSON project file.

I personally think what we need is a good way for the two build systems to share data, so that MSBuild can import data from a JSON project file.

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE May 12, 2016

Yes; that is what part of being a Build Master and putting on your resume that you speak MSBUILD means

Wellllll that's all nice and good and it is great to see all your investments/commitments to becoming/being a Build Master, but for a typical developer who simply wants to add a new task to their project to do x, y, z, their objective is to get those tasks in and back to developing code, not spending a week in required reading to figure out the simplest of features.

Again what is accomplished from this?

You're asking me what is accomplished by allowing developers to use the format they most prefer to work in? 😄 Web developers REALLY like their JSON and native developers really like their XML/Xaml. Soooo...

And of course, there are other formats altogether that developers enjoy. By embracing and enabling support for them (which can be done on a 3rd party basis, not from MSBuild itself) you encourage adoption.

Yes; that is what part of being a Build Master and putting on your resume that you speak MSBUILD means

Wellllll that's all nice and good and it is great to see all your investments/commitments to becoming/being a Build Master, but for a typical developer who simply wants to add a new task to their project to do x, y, z, their objective is to get those tasks in and back to developing code, not spending a week in required reading to figure out the simplest of features.

Again what is accomplished from this?

You're asking me what is accomplished by allowing developers to use the format they most prefer to work in? 😄 Web developers REALLY like their JSON and native developers really like their XML/Xaml. Soooo...

And of course, there are other formats altogether that developers enjoy. By embracing and enabling support for them (which can be done on a 3rd party basis, not from MSBuild itself) you encourage adoption.

@SolalPirelli

This comment has been minimized.

Show comment
Hide comment
@SolalPirelli

SolalPirelli May 12, 2016

Everybody agrees that we need a less arcane format for build files. I can't speak for Microsoft, but it does seem like they want to move in this direction as well.

What you don't seem to understand is that one can't just "enable support for 3rd-party providers" by flipping a switch somewhere. Creating a flexible enough API, documenting it and versioning it is far from trivial, MSBuild or otherwise.

Everybody agrees that we need a less arcane format for build files. I can't speak for Microsoft, but it does seem like they want to move in this direction as well.

What you don't seem to understand is that one can't just "enable support for 3rd-party providers" by flipping a switch somewhere. Creating a flexible enough API, documenting it and versioning it is far from trivial, MSBuild or otherwise.

@aolszowka

This comment has been minimized.

Show comment
Hide comment
@aolszowka

aolszowka May 12, 2016

typical developer who simply wants to add a new task to their project to do x, y, z

It would be helpful to understand what you're asking the project to do. Looking at project.json (I had never heard of this project until today) I only see limitations on what I'm able to do. For one there is no readily apparent ability for me to extend their project system with custom tasks (something any one who utilizes MSBUILD will eventually do).

The concept of native NuGet Package management seems nice; but is hardly novel.

not spending a week in required reading to figure out the simplest of features.

Again if you could tell us those features that you feel are hard to discover and would take a week of reading?

In reality, a significant portion of developers will never find themselves editing the csproj or any other msbuild based file by hand. The vast majority of them are interacting with the system via Visual Studio. Those that are editing in these files generally are reading the documentation or are using wrappers around the system such as TeamCity, Jenkins, or Team Foundation Server (TFS/Visual Studio Online whatever you wanna call it these days).

If you're attempting to target an audience that is not using Visual Studio then they should be encouraged to seek out the recommended project system of choice for their environment.

most prefer to work in?

I'm asking what these developers are doing and why they're not using the tooling provided to them?

By embracing and enabling support for them (which can be done on a 3rd party basis, not from MSBuild itself) you encourage adoption.

This is great in theory; however in practice it results in a contract being formed between Microsoft and these 3rd Parties; Raymond Chen speaks at length about such subjects as they are a recurring theme in the history of Microsoft developed products. Offering such a system results only in additional technical debt, and unless there is an extremely compelling reason most teams are wise to not take on such debt.

But back to your original post as I feel we're far off topic

MSBuild format is rooted in an arbitrary, not well-defined/known schema (difficult to explore and discover).

You need to qualify what you mean by this; the schema provides an XSD by which the project file can be validated http://schemas.microsoft.com/developer/msbuild/2003 this doesn't help you if you're using custom tasks, for which you should have provided the XSD when you wrote the tasks. Many community based projects such as the MSBuild Extension Pack and the MSBuild Community Tasks do this.

The format is well documented on MSDN (https://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx), an exploration of the project syntax is relativity straight forward to me personally.

If you could give a specific example of a common task developers are engaging in that is hindered by the current format it'd help to understand your request.

Create a well-defined, well-known .NET object model that defines the Project Model (Project API)

Believe it or not what you ask for already exists for MSBuild; however officially it is not a sanctioned binary for third party use and the API's are not guaranteed to change. However based on the widespread usage it has become defacto (probably much to the team's displeasure). The much API in question lives in Microsoft.Build; the most familiar of which to me is Microsoft.Build.Evaluation (https://msdn.microsoft.com/en-us/library/microsoft.build.evaluation.aspx).

Anyone who has done extensive deep dives into creating custom tasks or extending Visual Studio will be familiar with these API's.

Perhaps a better ask of the team is to make these API's sanctioned such that the third parties you mention can more reliably write to the specification.

typical developer who simply wants to add a new task to their project to do x, y, z

It would be helpful to understand what you're asking the project to do. Looking at project.json (I had never heard of this project until today) I only see limitations on what I'm able to do. For one there is no readily apparent ability for me to extend their project system with custom tasks (something any one who utilizes MSBUILD will eventually do).

The concept of native NuGet Package management seems nice; but is hardly novel.

not spending a week in required reading to figure out the simplest of features.

Again if you could tell us those features that you feel are hard to discover and would take a week of reading?

In reality, a significant portion of developers will never find themselves editing the csproj or any other msbuild based file by hand. The vast majority of them are interacting with the system via Visual Studio. Those that are editing in these files generally are reading the documentation or are using wrappers around the system such as TeamCity, Jenkins, or Team Foundation Server (TFS/Visual Studio Online whatever you wanna call it these days).

If you're attempting to target an audience that is not using Visual Studio then they should be encouraged to seek out the recommended project system of choice for their environment.

most prefer to work in?

I'm asking what these developers are doing and why they're not using the tooling provided to them?

By embracing and enabling support for them (which can be done on a 3rd party basis, not from MSBuild itself) you encourage adoption.

This is great in theory; however in practice it results in a contract being formed between Microsoft and these 3rd Parties; Raymond Chen speaks at length about such subjects as they are a recurring theme in the history of Microsoft developed products. Offering such a system results only in additional technical debt, and unless there is an extremely compelling reason most teams are wise to not take on such debt.

But back to your original post as I feel we're far off topic

MSBuild format is rooted in an arbitrary, not well-defined/known schema (difficult to explore and discover).

You need to qualify what you mean by this; the schema provides an XSD by which the project file can be validated http://schemas.microsoft.com/developer/msbuild/2003 this doesn't help you if you're using custom tasks, for which you should have provided the XSD when you wrote the tasks. Many community based projects such as the MSBuild Extension Pack and the MSBuild Community Tasks do this.

The format is well documented on MSDN (https://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx), an exploration of the project syntax is relativity straight forward to me personally.

If you could give a specific example of a common task developers are engaging in that is hindered by the current format it'd help to understand your request.

Create a well-defined, well-known .NET object model that defines the Project Model (Project API)

Believe it or not what you ask for already exists for MSBuild; however officially it is not a sanctioned binary for third party use and the API's are not guaranteed to change. However based on the widespread usage it has become defacto (probably much to the team's displeasure). The much API in question lives in Microsoft.Build; the most familiar of which to me is Microsoft.Build.Evaluation (https://msdn.microsoft.com/en-us/library/microsoft.build.evaluation.aspx).

Anyone who has done extensive deep dives into creating custom tasks or extending Visual Studio will be familiar with these API's.

Perhaps a better ask of the team is to make these API's sanctioned such that the third parties you mention can more reliably write to the specification.

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE May 12, 2016

this doesn't help you if you're using custom tasks, for which you should have provided the XSD when you wrote the tasks

That sounds like -- and is -- a lot of work. 😛 The goal/ask here is to make this more of a POCO based model where we are working with well-known/well-defined POCOs, and the objects that are serialized/deserialized are these objects. Otherwise, we are asking developers to add "yet another artifact" with an .xsd file (are these even used anymore these days?) to use as a schema when they have already defined the schema with the Task object they have created.

If you could give a specific example of a common task developers are engaging in that is hindered by the current format it'd help to understand your request.

I am open to admitting that I might (most probably) using the wrong words in describing my problem. I am fundamentally lazy and don't like thinking about things until it really matters, like you are pushing me to do! Essentially, there are two scenarios here to consider:

  1. Build master (experts)
  2. Developers (script kiddies/interested in becoming a build master -- hey, that's me!)

I will speak from my perspective (developer -- but I do have a lot of experience with TFS build servers). To start with, I will provide context when I go to open a Xaml file. When I open a Xaml file, every symbol on that file -- regardless of the type -- is easily accessible to me. Using ReSharper, I can CTRL-B any symbol on that file, and I will be taken to its (decomiled) definition. This happens every time, no question.

Now, for MSBuild, I have to open up the project to edit it. First, it produces a very disruptive dialog if I want to close all files in the project to view this file. Secondly, once the file opens, discoverability is next to zero. Not to mention the conceptual paradigm in play is very awkward. If I I want to get a list of files, I have to work with these PropertyGroup and ItemGroup tags and work with a strange syntax to collect my files.

Whereas in Xaml I could see something more well-formed such as:

<msbuild:Project>
    <msbuild:Project.Resources>
        <msbuild:FileList x:Name="FilesToDelete" Files="SomeDirectory/**.*" />
    <msbuild:Project.Resouces>
    <msbuild:Project.Tasks>
       <msbuild:DeleteFilesTask Files="{x:Reference FilesToDelete}" />
    </msbuild:Project.Tasks>
</msbuild:Project>

(note that is a REALLY ROUGH sketch of what I would possibly like to see in an API model. Please don't make too much fun of it. 😛 But the point here is that as I am typing, tooling kicks in and I am able to reference tasks as I write them as they are POCOs resolved to assemblies I have referenced.

I'm asking what these developers are doing and why they're not using the tooling provided to them?

That's just the problem. This is no tooling provided to XML editing of MSBuild files. Well there is, but it is very prohibitive when compared to, say, Xaml editing experience.

Perhaps a better ask of the team is to make these API's sanctioned such that the third parties you mention can more reliably write to the specification.

Like I said this is just to get the conversation going. Looks like I posted in the right place! 😄 Thank you for providing your input/perspective. I can tell you know what you're talking about! And also, give me your Twitter handle so I can tag you when I get pwned by the JSON crowd. (kidding... sorta 😄 )

this doesn't help you if you're using custom tasks, for which you should have provided the XSD when you wrote the tasks

That sounds like -- and is -- a lot of work. 😛 The goal/ask here is to make this more of a POCO based model where we are working with well-known/well-defined POCOs, and the objects that are serialized/deserialized are these objects. Otherwise, we are asking developers to add "yet another artifact" with an .xsd file (are these even used anymore these days?) to use as a schema when they have already defined the schema with the Task object they have created.

If you could give a specific example of a common task developers are engaging in that is hindered by the current format it'd help to understand your request.

I am open to admitting that I might (most probably) using the wrong words in describing my problem. I am fundamentally lazy and don't like thinking about things until it really matters, like you are pushing me to do! Essentially, there are two scenarios here to consider:

  1. Build master (experts)
  2. Developers (script kiddies/interested in becoming a build master -- hey, that's me!)

I will speak from my perspective (developer -- but I do have a lot of experience with TFS build servers). To start with, I will provide context when I go to open a Xaml file. When I open a Xaml file, every symbol on that file -- regardless of the type -- is easily accessible to me. Using ReSharper, I can CTRL-B any symbol on that file, and I will be taken to its (decomiled) definition. This happens every time, no question.

Now, for MSBuild, I have to open up the project to edit it. First, it produces a very disruptive dialog if I want to close all files in the project to view this file. Secondly, once the file opens, discoverability is next to zero. Not to mention the conceptual paradigm in play is very awkward. If I I want to get a list of files, I have to work with these PropertyGroup and ItemGroup tags and work with a strange syntax to collect my files.

Whereas in Xaml I could see something more well-formed such as:

<msbuild:Project>
    <msbuild:Project.Resources>
        <msbuild:FileList x:Name="FilesToDelete" Files="SomeDirectory/**.*" />
    <msbuild:Project.Resouces>
    <msbuild:Project.Tasks>
       <msbuild:DeleteFilesTask Files="{x:Reference FilesToDelete}" />
    </msbuild:Project.Tasks>
</msbuild:Project>

(note that is a REALLY ROUGH sketch of what I would possibly like to see in an API model. Please don't make too much fun of it. 😛 But the point here is that as I am typing, tooling kicks in and I am able to reference tasks as I write them as they are POCOs resolved to assemblies I have referenced.

I'm asking what these developers are doing and why they're not using the tooling provided to them?

That's just the problem. This is no tooling provided to XML editing of MSBuild files. Well there is, but it is very prohibitive when compared to, say, Xaml editing experience.

Perhaps a better ask of the team is to make these API's sanctioned such that the third parties you mention can more reliably write to the specification.

Like I said this is just to get the conversation going. Looks like I posted in the right place! 😄 Thank you for providing your input/perspective. I can tell you know what you're talking about! And also, give me your Twitter handle so I can tag you when I get pwned by the JSON crowd. (kidding... sorta 😄 )

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE May 12, 2016

What you don't seem to understand is that one can't just "enable support for 3rd-party providers" by flipping a switch somewhere

Isn't that exactly what the ASP.NET Core team did with its configuration provider API? That's pretty much the same idea here.

What you don't seem to understand is that one can't just "enable support for 3rd-party providers" by flipping a switch somewhere

Isn't that exactly what the ASP.NET Core team did with its configuration provider API? That's pretty much the same idea here.

@SolalPirelli

This comment has been minimized.

Show comment
Hide comment
@SolalPirelli

SolalPirelli May 12, 2016

Isn't that exactly what the ASP.NET Core team did with its configuration provider API? That's pretty much the same idea here.

The ASP.NET team made the choice of accepting third-party configuration models, yes, and I'm sure they had good reasons to make that tradeoff; the fact that they needed to implement multiple configuration providers anyway for things like environment vars and config files probably factored into that discussion. In exchange for that flexibility, they get more complexity.

However, you have not given a good argument as to why MSBuild should become more complex. "It's the current fad in web development" is not a good argument.

This entire thread looks like the XY problem to me: you want to have a better MSBuild format, which is great, but you think it can only be achieved via your idea - to let everybody provide their own format - when there are plenty of other solutions out there.

Isn't that exactly what the ASP.NET Core team did with its configuration provider API? That's pretty much the same idea here.

The ASP.NET team made the choice of accepting third-party configuration models, yes, and I'm sure they had good reasons to make that tradeoff; the fact that they needed to implement multiple configuration providers anyway for things like environment vars and config files probably factored into that discussion. In exchange for that flexibility, they get more complexity.

However, you have not given a good argument as to why MSBuild should become more complex. "It's the current fad in web development" is not a good argument.

This entire thread looks like the XY problem to me: you want to have a better MSBuild format, which is great, but you think it can only be achieved via your idea - to let everybody provide their own format - when there are plenty of other solutions out there.

@SamuelEnglard

This comment has been minimized.

Show comment
Hide comment
@SamuelEnglard

SamuelEnglard May 12, 2016

@Mike-EEE The issue is more that you know the XAML APIs and (admittedly) the editor experience is less friendly for MSBuild. But if you really want to learn http://www.amazon.com/Inside-Microsoft-Build-Engine-Foundation/dp/0735645248?ie=UTF8&psc=1&redirect=true&ref_=oh_aui_detailpage_o00_s00

@Mike-EEE The issue is more that you know the XAML APIs and (admittedly) the editor experience is less friendly for MSBuild. But if you really want to learn http://www.amazon.com/Inside-Microsoft-Build-Engine-Foundation/dp/0735645248?ie=UTF8&psc=1&redirect=true&ref_=oh_aui_detailpage_o00_s00

@colin-young

This comment has been minimized.

Show comment
Hide comment
@colin-young

colin-young May 12, 2016

You can count me in the project.json camp, although what I loved about it was the simplicity:

  • here's my project name and description
  • here are the target frameworks I want supported and here are the dependencies for each
  • here are my framework-independent dependencies (more often than not, none)
  • done. Here's your NuGet package.

I don't care what format you use to instruct the toolchain to build my project as long as it is documented, I can edit it by hand (because sometimes NuGet just gets confused) and I can use the exact same thing on a dev box as on a build server and they both work exactly the same way.

Oh, and I don't need to maintain multiple files, one for VS to build my project and another one for NuGet to package it. Hey, VS, if you can figure out how to build it, I'm sure you can handle collecting everything and making a nice package for me.

You can count me in the project.json camp, although what I loved about it was the simplicity:

  • here's my project name and description
  • here are the target frameworks I want supported and here are the dependencies for each
  • here are my framework-independent dependencies (more often than not, none)
  • done. Here's your NuGet package.

I don't care what format you use to instruct the toolchain to build my project as long as it is documented, I can edit it by hand (because sometimes NuGet just gets confused) and I can use the exact same thing on a dev box as on a build server and they both work exactly the same way.

Oh, and I don't need to maintain multiple files, one for VS to build my project and another one for NuGet to package it. Hey, VS, if you can figure out how to build it, I'm sure you can handle collecting everything and making a nice package for me.

@SamuelEnglard

This comment has been minimized.

Show comment
Hide comment
@SamuelEnglard

SamuelEnglard May 12, 2016

Oh, and I don't need to maintain multiple files, one for VS to build my project and another one for NuGet to package it. Hey, VS, if you can figure out how to build it, I'm sure you can handle collecting everything and making a nice package for me.

See https://github.com/nuproj/nuproj by @terrajobst

Oh, and I don't need to maintain multiple files, one for VS to build my project and another one for NuGet to package it. Hey, VS, if you can figure out how to build it, I'm sure you can handle collecting everything and making a nice package for me.

See https://github.com/nuproj/nuproj by @terrajobst

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE May 12, 2016

However, you have not given a good argument as to why MSBuild should become more complex. "It's the current fad in web development" is not a good argument

Again, not making it more complex, but reducing its complexity. It's not just a fad in web development but a viable, popular pattern that has been used for quite some time in .NET. The ask would be to utilize this pattern for serializing objects that are used to describe MSBuild projects in a way that allows developers/organizations/teams to use the format they prefer.

I am starting to get the feeling that we should wait until more developers from the pro-JSON camp find their way onto this thread before attempting to provide a better argument. ;)

This entire thread looks like the XY problem to me: you want to have a better MSBuild format, which is great, but you think it can only be achieved via your idea - to let everybody provide their own format - when there are plenty of other solutions out there.

Haha... that's cool. I learned something new today. Thank you for the link 😄 My idea is to provide a better model (which it sounds like everyone agrees with!) which can then be serialized/deserialized in any format, if that helps clarify my position.

However, you have not given a good argument as to why MSBuild should become more complex. "It's the current fad in web development" is not a good argument

Again, not making it more complex, but reducing its complexity. It's not just a fad in web development but a viable, popular pattern that has been used for quite some time in .NET. The ask would be to utilize this pattern for serializing objects that are used to describe MSBuild projects in a way that allows developers/organizations/teams to use the format they prefer.

I am starting to get the feeling that we should wait until more developers from the pro-JSON camp find their way onto this thread before attempting to provide a better argument. ;)

This entire thread looks like the XY problem to me: you want to have a better MSBuild format, which is great, but you think it can only be achieved via your idea - to let everybody provide their own format - when there are plenty of other solutions out there.

Haha... that's cool. I learned something new today. Thank you for the link 😄 My idea is to provide a better model (which it sounds like everyone agrees with!) which can then be serialized/deserialized in any format, if that helps clarify my position.

@aolszowka

This comment has been minimized.

Show comment
Hide comment
@aolszowka

aolszowka May 12, 2016

with an .xsd file (are these even used anymore these days?) to use as a schema when they have already defined the schema with the Task object they have created.

Yes; they're used all the time. In your Xaml example its how Intellisense (and other such tools) knows what to present to you and how XML files are validated as "well formed". The JSON Kids haven't grown up enough yet to understand why such systems are required; it looks like they're starting to come around though based on a quick google search.

When I open a Xaml file, every symbol on that file -- regardless of the type -- is easily accessible to me.

You're asking for Intellisense; again provided by a valid XSD which is automatically loaded as per the directive at the top of every well formed msbuild project file. Out of the box this is only provided for the included "base" MSBuild tasks.

Does the one provided within Visual Studio not meet your needs? Below is a screen shot from one of our build scripts showing this in action:

intellisenseformsbuild

A reasonable ask I think is to ask for more context documentation here to improve discover-ability; however that is for another subject; one I'd gladly up-vote as I know when I was starting out it was frustrating to continue to reference back to the documentation.

First, it produces a very disruptive dialog if I want to close all files in the project to view this file.

This is a limitation of Visual Studio; not of the chosen file format.

no tooling provided to XML editing of MSBuild files

Again, any XML capable editor can do this; I personally recommend Visual Studio simply because it will parse the XSD and any other included namespace to give you contextual Intellisense/Code completion.

And also, give me your Twitter handle

I've been told I need one; but honestly have never bothered to get on there. Feel free to @mention me anywhere on GitHub though.

with an .xsd file (are these even used anymore these days?) to use as a schema when they have already defined the schema with the Task object they have created.

Yes; they're used all the time. In your Xaml example its how Intellisense (and other such tools) knows what to present to you and how XML files are validated as "well formed". The JSON Kids haven't grown up enough yet to understand why such systems are required; it looks like they're starting to come around though based on a quick google search.

When I open a Xaml file, every symbol on that file -- regardless of the type -- is easily accessible to me.

You're asking for Intellisense; again provided by a valid XSD which is automatically loaded as per the directive at the top of every well formed msbuild project file. Out of the box this is only provided for the included "base" MSBuild tasks.

Does the one provided within Visual Studio not meet your needs? Below is a screen shot from one of our build scripts showing this in action:

intellisenseformsbuild

A reasonable ask I think is to ask for more context documentation here to improve discover-ability; however that is for another subject; one I'd gladly up-vote as I know when I was starting out it was frustrating to continue to reference back to the documentation.

First, it produces a very disruptive dialog if I want to close all files in the project to view this file.

This is a limitation of Visual Studio; not of the chosen file format.

no tooling provided to XML editing of MSBuild files

Again, any XML capable editor can do this; I personally recommend Visual Studio simply because it will parse the XSD and any other included namespace to give you contextual Intellisense/Code completion.

And also, give me your Twitter handle

I've been told I need one; but honestly have never bothered to get on there. Feel free to @mention me anywhere on GitHub though.

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE May 12, 2016

@SamuelEnglard yeah I hate to mention Xaml here, because the Xaml that is already in use that is associated (very negatively i might add) with MSBuild is actually Windows Workflow and is really a bear to use (really, EVERYONE hates it and do not want "Xaml" because of it). I personally would like to see Xaml used to describe MSBuild files so it would be more like the current XML approach, but much more well-defined and discoverable.

Mike-EEE commented May 12, 2016

@SamuelEnglard yeah I hate to mention Xaml here, because the Xaml that is already in use that is associated (very negatively i might add) with MSBuild is actually Windows Workflow and is really a bear to use (really, EVERYONE hates it and do not want "Xaml" because of it). I personally would like to see Xaml used to describe MSBuild files so it would be more like the current XML approach, but much more well-defined and discoverable.

@colin-young

This comment has been minimized.

Show comment
Hide comment
@colin-young

colin-young May 12, 2016

See https://github.com/nuproj/nuproj by @terrajobst

Yeah, no. That's still requiring me to duplicate information. The only reason I should ever need to specify some bit on info again is because I want it to be different than somewhere else. e.g. If I have AssemblyInfo.cs in my project and I want the assembly versions to be different than the version of the NuGet package, then I would specify each. Otherwise, setting one should flow into the other.

I should be able to describe everything about my project in a single location. I should also not need to tell NuGet that I want it to take the output of my project and use that in the package. Why wouldn't I want to include that? And if I've already specified which frameworks to generate assemblies for, why do I need to explain which targets are being packaged, again? Pick all of them, unless I tell you otherwise.

Sensible defaults and a mechanism to override them...

See https://github.com/nuproj/nuproj by @terrajobst

Yeah, no. That's still requiring me to duplicate information. The only reason I should ever need to specify some bit on info again is because I want it to be different than somewhere else. e.g. If I have AssemblyInfo.cs in my project and I want the assembly versions to be different than the version of the NuGet package, then I would specify each. Otherwise, setting one should flow into the other.

I should be able to describe everything about my project in a single location. I should also not need to tell NuGet that I want it to take the output of my project and use that in the package. Why wouldn't I want to include that? And if I've already specified which frameworks to generate assemblies for, why do I need to explain which targets are being packaged, again? Pick all of them, unless I tell you otherwise.

Sensible defaults and a mechanism to override them...

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE May 12, 2016

You're asking for Intellisense

Actually, no I am asking for more than that (from what I understand). Intellisense completes the symbols, and provides tooltips, but to actually dive into the symbol to take you directly to the class file where it exists, that is an IDE (or tooling, such as ReSharper) implementation detail.

Does the one provided within Visual Studio not meet your needs?

It's OK. But I find the Xaml experience much more expressive and discoverable. And intuitive as well. And I am not entirely sure that Xaml is using .xsd files, unless they are automatically creating them from the class definitions? That seems inefficient as the class definitions are already in memory and available to to the tools. It doesn't make sense to create a whole new file and then use that for navigation/information.

Also, another aspect we're overlooking here is .SLN files, which are their own animal (beast, more like it!) altogether and should be tamed/consolidated/considered into this new model as well.

Mike-EEE commented May 12, 2016

You're asking for Intellisense

Actually, no I am asking for more than that (from what I understand). Intellisense completes the symbols, and provides tooltips, but to actually dive into the symbol to take you directly to the class file where it exists, that is an IDE (or tooling, such as ReSharper) implementation detail.

Does the one provided within Visual Studio not meet your needs?

It's OK. But I find the Xaml experience much more expressive and discoverable. And intuitive as well. And I am not entirely sure that Xaml is using .xsd files, unless they are automatically creating them from the class definitions? That seems inefficient as the class definitions are already in memory and available to to the tools. It doesn't make sense to create a whole new file and then use that for navigation/information.

Also, another aspect we're overlooking here is .SLN files, which are their own animal (beast, more like it!) altogether and should be tamed/consolidated/considered into this new model as well.

@SamuelEnglard

This comment has been minimized.

Show comment
Hide comment
@SamuelEnglard

SamuelEnglard May 12, 2016

@colin-young because it's all MSBuild you can "embed" it into the existing project and have it pull the information from there. I think I'll fork it to add an example of doing that...

I've added #614 to discuses a better experience editing the XML since that's really off topic for this issue

@colin-young because it's all MSBuild you can "embed" it into the existing project and have it pull the information from there. I think I'll fork it to add an example of doing that...

I've added #614 to discuses a better experience editing the XML since that's really off topic for this issue

@aolszowka

This comment has been minimized.

Show comment
Hide comment
@aolszowka

aolszowka May 12, 2016

@colin-young

If I understand what you're asking for you want a workflow in which NuGet package creation is more tightly coupled with the build; this is already possible in MSBuild; it would require that you add a new target to your existing msbuild file and then call the target at the appropriate time; if you were using MSBuild Community Tasks you'd call the NuGetPack Task as appropriate (here's a snippet from one of our projects):

<NuGetPack File="%(NSPSTransformed.Identity)" OutputDirectory="$(BuildOutputNuGet)" Properties="Configuration=Release" IncludeReferencedProjects="true" ToolPath="$(nugetToolPath)" />

Reading between the lines you want a system that does this for you automagically; I'm not sure that specific business needs should be covered by the tool by default. At some point you will need to customize and modify the tools to fulfill your needs.

@colin-young

If I understand what you're asking for you want a workflow in which NuGet package creation is more tightly coupled with the build; this is already possible in MSBuild; it would require that you add a new target to your existing msbuild file and then call the target at the appropriate time; if you were using MSBuild Community Tasks you'd call the NuGetPack Task as appropriate (here's a snippet from one of our projects):

<NuGetPack File="%(NSPSTransformed.Identity)" OutputDirectory="$(BuildOutputNuGet)" Properties="Configuration=Release" IncludeReferencedProjects="true" ToolPath="$(nugetToolPath)" />

Reading between the lines you want a system that does this for you automagically; I'm not sure that specific business needs should be covered by the tool by default. At some point you will need to customize and modify the tools to fulfill your needs.

@aolszowka

This comment has been minimized.

Show comment
Hide comment
@aolszowka

aolszowka May 12, 2016

@Mike-EEE

but to actually dive into the symbol to take you directly to the class file where it exists

Its not clear what you would gain from being shown the source for a task such as "Move" or "Copy" 99% of the time unless you're debugging a bug within those tasks you're more interested in what the attributes (arguments) to the task are and what its behavior is; all of this can be embedded in the XSD; the version that they have provided and maintained is very simplistic covering only the built in tasks and the various attributes (IE "arguments") to be passed into the task.

And intuitive as well. And I am not entirely sure that Xaml is using .xsd files

Its slightly more complex than that Intellisense will utilize methods such as comment scraping for XML Docs to generate this information on the fly; but the end results are the same.

It doesn't make sense to create a whole new file and then use that for navigation/information.

Why not? The file is created in memory if anything.

Also, another aspect we're overlooking here is .SLN files, which are their own animal (beast, more like it!) altogether and should be tamed/consolidated/considered into this new model as well.

If you look at how MSBuild handles SLN files; they are actually transformed by MSBuild into pseudo MSBuild files prior to execution to avoid the nastiness incurred within them. However that being said I found the format straight forward; if you created another issue page to air your complaints with them I'm sure we can show you how they operate.

They are also editable via the above linked API.

@Mike-EEE

but to actually dive into the symbol to take you directly to the class file where it exists

Its not clear what you would gain from being shown the source for a task such as "Move" or "Copy" 99% of the time unless you're debugging a bug within those tasks you're more interested in what the attributes (arguments) to the task are and what its behavior is; all of this can be embedded in the XSD; the version that they have provided and maintained is very simplistic covering only the built in tasks and the various attributes (IE "arguments") to be passed into the task.

And intuitive as well. And I am not entirely sure that Xaml is using .xsd files

Its slightly more complex than that Intellisense will utilize methods such as comment scraping for XML Docs to generate this information on the fly; but the end results are the same.

It doesn't make sense to create a whole new file and then use that for navigation/information.

Why not? The file is created in memory if anything.

Also, another aspect we're overlooking here is .SLN files, which are their own animal (beast, more like it!) altogether and should be tamed/consolidated/considered into this new model as well.

If you look at how MSBuild handles SLN files; they are actually transformed by MSBuild into pseudo MSBuild files prior to execution to avoid the nastiness incurred within them. However that being said I found the format straight forward; if you created another issue page to air your complaints with them I'm sure we can show you how they operate.

They are also editable via the above linked API.

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE May 12, 2016

Its not clear what you would gain from being shown the source for a task such as "Move" or "Copy" 99% of the time unless you're debugging a bug within those tasks you're more interested in what the attributes (arguments) to the task are and what its behavior is

What you gain is a sense of discoverability and access -- not just for the default items described by the xsd but any object defined in the file. You get clear connection to the data you are describing and the object that ends up using those values. If you have not spent a lot of time in Xaml then it might not make sense to you, but when you have access to your code and can easily navigate through its properties and definitions, you not only get a better understanding of the elements at play, but also for the system as a whole. This is what is so awesome about .NET in general: being able to explore elements and see how they all connect and how they can be utilized.

Why not? The file is created in memory if anything.

Again, I am not sure if this takes place. Can you provide a resource showing that XSDs are used for intellisense? This is the first I have heard of this. And if a process is creating "yet another file" -- even in memory -- when the data it seeks is already in memory by way of symbols culled from a class definition, then obviously that is a very inefficient approach!

if you created another issue page to air your complaints with them

Truth be told, I have already done that here:
https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/9347001-improve-reboot-visual-studio-project-system

:)

Its not clear what you would gain from being shown the source for a task such as "Move" or "Copy" 99% of the time unless you're debugging a bug within those tasks you're more interested in what the attributes (arguments) to the task are and what its behavior is

What you gain is a sense of discoverability and access -- not just for the default items described by the xsd but any object defined in the file. You get clear connection to the data you are describing and the object that ends up using those values. If you have not spent a lot of time in Xaml then it might not make sense to you, but when you have access to your code and can easily navigate through its properties and definitions, you not only get a better understanding of the elements at play, but also for the system as a whole. This is what is so awesome about .NET in general: being able to explore elements and see how they all connect and how they can be utilized.

Why not? The file is created in memory if anything.

Again, I am not sure if this takes place. Can you provide a resource showing that XSDs are used for intellisense? This is the first I have heard of this. And if a process is creating "yet another file" -- even in memory -- when the data it seeks is already in memory by way of symbols culled from a class definition, then obviously that is a very inefficient approach!

if you created another issue page to air your complaints with them

Truth be told, I have already done that here:
https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/9347001-improve-reboot-visual-studio-project-system

:)

@colin-young

This comment has been minimized.

Show comment
Hide comment
@colin-young

colin-young May 12, 2016

@SamuelEnglard @aolszowka This thread started from dotnet/roslyn#11235, which was about improving the project definition format. To your point, what I'd like is a declarative project format rather than prescriptive. MSBuild is, by necessity, prescriptive. 90% of the time, I don't care how it accomplishes that because I just want to say, "Hey .Net, see all these files? Can you compile them all into an assembly and then package it for all of these targets? Here's all the details of what to name it and the version."

To me the question is, should the tool that takes a declarative description of a project and produces the requested output be part of MSBuild, or part of something else? But I do feel very strongly that it needs to be standard across all of .Net (i.e. one file format on Windows, Linux, OS X whether you are using the command line or Visual Studio).

@SamuelEnglard @aolszowka This thread started from dotnet/roslyn#11235, which was about improving the project definition format. To your point, what I'd like is a declarative project format rather than prescriptive. MSBuild is, by necessity, prescriptive. 90% of the time, I don't care how it accomplishes that because I just want to say, "Hey .Net, see all these files? Can you compile them all into an assembly and then package it for all of these targets? Here's all the details of what to name it and the version."

To me the question is, should the tool that takes a declarative description of a project and produces the requested output be part of MSBuild, or part of something else? But I do feel very strongly that it needs to be standard across all of .Net (i.e. one file format on Windows, Linux, OS X whether you are using the command line or Visual Studio).

@MarkPflug

This comment has been minimized.

Show comment
Hide comment
@MarkPflug

MarkPflug May 12, 2016

@colin-young You can put your version number in an MSBuild file and have your AssemblyInfo.cs (or part of it) generated by an MSBuild task. I've done this for my work projects, because we have ~100 projects that we want to build with the same version. Now, we only have the one place to maintain that version number. This same version property could be fed into the task that builds the nuget packages.

CommonAssemblyInfo.targets:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

    <PropertyGroup>    
        <Year>$([System.DateTime]::Now.Year)</Year>
        <Version>1.2.3</Version>
        <Company>FooBar Technologies</Company>        
        <Copyright>© $(Year) $(Company)</Copyright>
        <CommonAssemblyInfoFileName>CommonAssemblyInfo.cs</CommonAssemblyInfoFileName>
    </PropertyGroup>

    <ItemGroup>
        <Compile Include="$(CommonAssemblyInfoFileName)"/>
    </ItemGroup>

    <Target Name="CleanCommonAssemblyInfo" BeforeTargets="Clean">
        <Delete Files="$(CommonAssemblyInfoFileName)" Condition="Exists('$(CommonAssemblyInfoFileName)')"/>
    </Target>

    <Target Name="CreateCommonAssemblyInfo" BeforeTargets="CoreCompile">
        <ItemGroup>
            <AssemblyAttributes Include="AssemblyVersion">
                <_Parameter1>$(Version).0</_Parameter1>
            </AssemblyAttributes>
            <AssemblyAttributes Include="AssemblyInformationalVersion">
                <_Parameter1>$(Version).0</_Parameter1>
            </AssemblyAttributes>
            <AssemblyAttributes Include="AssemblyFileVersion">
                <_Parameter1>$(Version).$(BuildNumber)</_Parameter1>
            </AssemblyAttributes>
            <AssemblyAttributes Include="AssemblyCompany">
                <_Parameter1>$(Company)</_Parameter1>
            </AssemblyAttributes>
            <AssemblyAttributes Include="AssemblyCopyright">
                <_Parameter1>$(Copyright)</_Parameter1>
            </AssemblyAttributes>
        </ItemGroup>

        <WriteCodeFragment 
            Language="C#"           
            OutputFile="$(CommonAssemblyInfoFileName)"
            AssemblyAttributes="@(AssemblyAttributes)" 
        />
    </Target>
</Project>

Just Import this targets file into your .csproj file. (It might need some tweaks, I sanitized this from the one that we use. This way you also don't need to remember to update your copyright year every time the earth laps the sun.

@colin-young You can put your version number in an MSBuild file and have your AssemblyInfo.cs (or part of it) generated by an MSBuild task. I've done this for my work projects, because we have ~100 projects that we want to build with the same version. Now, we only have the one place to maintain that version number. This same version property could be fed into the task that builds the nuget packages.

CommonAssemblyInfo.targets:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

    <PropertyGroup>    
        <Year>$([System.DateTime]::Now.Year)</Year>
        <Version>1.2.3</Version>
        <Company>FooBar Technologies</Company>        
        <Copyright>© $(Year) $(Company)</Copyright>
        <CommonAssemblyInfoFileName>CommonAssemblyInfo.cs</CommonAssemblyInfoFileName>
    </PropertyGroup>

    <ItemGroup>
        <Compile Include="$(CommonAssemblyInfoFileName)"/>
    </ItemGroup>

    <Target Name="CleanCommonAssemblyInfo" BeforeTargets="Clean">
        <Delete Files="$(CommonAssemblyInfoFileName)" Condition="Exists('$(CommonAssemblyInfoFileName)')"/>
    </Target>

    <Target Name="CreateCommonAssemblyInfo" BeforeTargets="CoreCompile">
        <ItemGroup>
            <AssemblyAttributes Include="AssemblyVersion">
                <_Parameter1>$(Version).0</_Parameter1>
            </AssemblyAttributes>
            <AssemblyAttributes Include="AssemblyInformationalVersion">
                <_Parameter1>$(Version).0</_Parameter1>
            </AssemblyAttributes>
            <AssemblyAttributes Include="AssemblyFileVersion">
                <_Parameter1>$(Version).$(BuildNumber)</_Parameter1>
            </AssemblyAttributes>
            <AssemblyAttributes Include="AssemblyCompany">
                <_Parameter1>$(Company)</_Parameter1>
            </AssemblyAttributes>
            <AssemblyAttributes Include="AssemblyCopyright">
                <_Parameter1>$(Copyright)</_Parameter1>
            </AssemblyAttributes>
        </ItemGroup>

        <WriteCodeFragment 
            Language="C#"           
            OutputFile="$(CommonAssemblyInfoFileName)"
            AssemblyAttributes="@(AssemblyAttributes)" 
        />
    </Target>
</Project>

Just Import this targets file into your .csproj file. (It might need some tweaks, I sanitized this from the one that we use. This way you also don't need to remember to update your copyright year every time the earth laps the sun.

@aolszowka

This comment has been minimized.

Show comment
Hide comment
@aolszowka

aolszowka May 12, 2016

@colin-young @MarkPflug Excellent; you can obviously chain that to whatever task you need; including the packaging of the NuGet Package and pushing out as needed.

"Hey .Net, see all these files? Can you compile them all into an assembly and then package it for all of these targets? Here's all the details of what to name it and the version."

I'm not sure what I'm missing here; this is exactly how msbuild can work; what have you tried?

@colin-young @MarkPflug Excellent; you can obviously chain that to whatever task you need; including the packaging of the NuGet Package and pushing out as needed.

"Hey .Net, see all these files? Can you compile them all into an assembly and then package it for all of these targets? Here's all the details of what to name it and the version."

I'm not sure what I'm missing here; this is exactly how msbuild can work; what have you tried?

@aolszowka

This comment has been minimized.

Show comment
Hide comment
@aolszowka

aolszowka May 12, 2016

@Mike-EEE

What you gain is a sense of discoverability and access -- not just for the default items described by the xsd but any object defined in the file.

Again I'm not sure what you gain by that; 75-80% of the content in a MSBuild Task is simply correctly hooking up the underlying tool into MSBuild and its logging system. You can validate this yourself by browsing the source or by Reflecting on the Binaries with your IL De-compiler of choice. You'll see the majority extend from the ToolTask helper abstract class to perform most of the dirty work.

You gain no additional insight into how the tooling should be used beyond implementation details which should not be relied upon.

I assure you I've spent plenty of time in Visual Studio in plenty of projects some of which utilize WPF pretty heavily; but I'm still missing where you feel this is any different than what is currently provided (but I will admit needs to be much better fleshed out).

Can you provide a resource showing that XSDs are used for intellisense? This is the first I have heard of this.

This is the first Google Result for "Intellisense xsd"; it provides a very good high level overview https://msdn.microsoft.com/en-us/library/ms255811.aspx if there is something more you need let me know. The documentation claims it only goes back to VS 2005; which seems to jive as that's when I started using VS.

And if a process is creating "yet another file" -- even in memory -- when the data it seeks is already in memory by way of symbols culled from a class definition, then obviously that is a very inefficient approach!

How do you think Intellisense is being provided to you right now? I'm not sure that you understand what you're arguing here, or maybe I'm completely off in left field as to why you think this is an issue. You realize that in order to gather documentation from XML Doc Comments Visual Studio is creating a structure (that can even be written out to an XML file) that contains the documentation for each function right?

All of that is beside the point; I strongly encourage you to take the time to understand how Intellisense works before continuing this discussion; starting here https://msdn.microsoft.com/en-us/library/hcw1s69b.aspx, here https://msdn.microsoft.com/en-us/library/s0we08bk.aspx, and here https://msdn.microsoft.com/en-us/library/microsoft.visualstudio.language.intellisense.icompletionsourceprovider.aspx

Thank you for that users voice link; I'll direct additional input there as needed.

@Mike-EEE

What you gain is a sense of discoverability and access -- not just for the default items described by the xsd but any object defined in the file.

Again I'm not sure what you gain by that; 75-80% of the content in a MSBuild Task is simply correctly hooking up the underlying tool into MSBuild and its logging system. You can validate this yourself by browsing the source or by Reflecting on the Binaries with your IL De-compiler of choice. You'll see the majority extend from the ToolTask helper abstract class to perform most of the dirty work.

You gain no additional insight into how the tooling should be used beyond implementation details which should not be relied upon.

I assure you I've spent plenty of time in Visual Studio in plenty of projects some of which utilize WPF pretty heavily; but I'm still missing where you feel this is any different than what is currently provided (but I will admit needs to be much better fleshed out).

Can you provide a resource showing that XSDs are used for intellisense? This is the first I have heard of this.

This is the first Google Result for "Intellisense xsd"; it provides a very good high level overview https://msdn.microsoft.com/en-us/library/ms255811.aspx if there is something more you need let me know. The documentation claims it only goes back to VS 2005; which seems to jive as that's when I started using VS.

And if a process is creating "yet another file" -- even in memory -- when the data it seeks is already in memory by way of symbols culled from a class definition, then obviously that is a very inefficient approach!

How do you think Intellisense is being provided to you right now? I'm not sure that you understand what you're arguing here, or maybe I'm completely off in left field as to why you think this is an issue. You realize that in order to gather documentation from XML Doc Comments Visual Studio is creating a structure (that can even be written out to an XML file) that contains the documentation for each function right?

All of that is beside the point; I strongly encourage you to take the time to understand how Intellisense works before continuing this discussion; starting here https://msdn.microsoft.com/en-us/library/hcw1s69b.aspx, here https://msdn.microsoft.com/en-us/library/s0we08bk.aspx, and here https://msdn.microsoft.com/en-us/library/microsoft.visualstudio.language.intellisense.icompletionsourceprovider.aspx

Thank you for that users voice link; I'll direct additional input there as needed.

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE May 12, 2016

@aolszowka LOL I think we are definitely getting our definitions crossed here (and don't get me wrong I really appreciate your dialogue!). I understand how Intellisense works from a functional standpoint, but from a technical standpoint, I do not see any evidence of intellisense being dependent upon (or relying on) an xsd to operate. The article you showed me explains how intellisense operates on an XSD, but it does not say that it requires an xsd to function. Does that make sense? Big difference. 😄

Again I'm not sure what you gain by that; 75-80% of the content in a MSBuild Task is simply correctly hooking up the underlying tool into MSBuild and its logging system

Right, and the tooling that provides for this is not as effective as say what you see in a Xaml-based context. Perhaps this is a matter of approach, but when learning a new API, I and the developers I know spend a lot of time navigating through objects/classes to learn the system. Documentation is really a 2nd thought and rarely used. In fact words get in the way of the real langage, the code! :)

You gain no additional insight into how the tooling should be used beyond implementation details which should not be relied upon

Yikes, this is a very narrow (bordering on close-minded!) view! This might be the case in actually bolting together a task and a "just get it done and never think about it again" sense, but developers (again, the good ones I know) like to explore. When you impede this process (or make it difficult), this provides poor experience. Poor developer experience results in poor adoption and even worse yet poor sentiment for your product.

This is why Xaml developers are really passionate about their Xaml, because of the experience that it offers, and that is part of the goal here -- to improve the developer experience this format and model.

Mike-EEE commented May 12, 2016

@aolszowka LOL I think we are definitely getting our definitions crossed here (and don't get me wrong I really appreciate your dialogue!). I understand how Intellisense works from a functional standpoint, but from a technical standpoint, I do not see any evidence of intellisense being dependent upon (or relying on) an xsd to operate. The article you showed me explains how intellisense operates on an XSD, but it does not say that it requires an xsd to function. Does that make sense? Big difference. 😄

Again I'm not sure what you gain by that; 75-80% of the content in a MSBuild Task is simply correctly hooking up the underlying tool into MSBuild and its logging system

Right, and the tooling that provides for this is not as effective as say what you see in a Xaml-based context. Perhaps this is a matter of approach, but when learning a new API, I and the developers I know spend a lot of time navigating through objects/classes to learn the system. Documentation is really a 2nd thought and rarely used. In fact words get in the way of the real langage, the code! :)

You gain no additional insight into how the tooling should be used beyond implementation details which should not be relied upon

Yikes, this is a very narrow (bordering on close-minded!) view! This might be the case in actually bolting together a task and a "just get it done and never think about it again" sense, but developers (again, the good ones I know) like to explore. When you impede this process (or make it difficult), this provides poor experience. Poor developer experience results in poor adoption and even worse yet poor sentiment for your product.

This is why Xaml developers are really passionate about their Xaml, because of the experience that it offers, and that is part of the goal here -- to improve the developer experience this format and model.

@aolszowka

This comment has been minimized.

Show comment
Hide comment
@aolszowka

aolszowka May 13, 2016

I do not see any evidence of intellisense being dependent upon (or relying on) an xsd to operate. The article you showed me explains how intellisense operates on an XSD, but it does not say that it requires an xsd to function.

Actually it does; right under the first header:

"After a schema is associated with your document, you get a drop-down list of expected elements any time you type "<" or click the Display an Object Member List button on the XML editor toolbar. For information about how to associate schemas with your XML documents, see XML Document Validation."

Please understand that in this context schema is an XSD (XML Schema Document).

Furthermore, reading the in-lined link (see XML Document Validation) clearly states:

"The XML Editor checks XML 1.0 syntax and also performs data validation as you type. The editor can validate using a document type definition (DTD) or a schema. Red wavy underlines highlight any XML 1.0 well-formed errors. Blue wavy underlines show semantic errors based on DTD or schema validation. Each error has an associated entry in the error list. You can also view the error message by pausing the mouse over the wavy underline."

And even further:

"When editing an XML Schema file, the xsdschema.xsd file located in the schema cache is used for validation. Validation errors are shown as blue wavy underlines. Any compilation errors are also shown with red wavy underlines."

In an MSBuild file this is implicitly loaded by the namespace command:

xmlns="http://schemas.microsoft.com/developer/msbuild/2003"

The exact same way it'd be loaded in for any Xaml or other XML based document format. This is not unique to any of these file formats but is part of the well-defined XML Document Standard.

The article you showed me explains how intellisense operates on an XSD, but it does not say that it requires an xsd to function. Does that make sense? Big difference.

That is a distinction without a difference; however, it is beside the point.

Right, and the tooling that provides for this is not as effective as say what you see in a Xaml-based context.

I'm not sure what you're saying here; I'm not sure how looking at the source of a Task (for example https://github.com/Microsoft/msbuild/blob/c1459f5cbd36f2c33eafc8f4ff087f6ee84c3640/src/XMakeTasks/Move.cs) gives you any insight on how the task (Move) is supposed to be used from within MSBuild; there is no requirement (although it is good practice) that a usage comment is associated with the code that defines the task.

Let’s for a moment say that they implemented what you described; When you were highlighted on a task name that hitting F12 (Go to Definition) took you to either the reference source or a decompiled version of the currently referenced assembly. What would your work flow look like if you were attempting to use the Task (not Debug the task)?

Yikes, this is a very narrow (bordering on close-minded!) view!

This is a view commonly shared by consumers of any API; understanding how the API call is implemented may serve some desire to understand how things work; but it will not explain to you how it should be integrated with other parts of the API to perform useful tasks, nor what the expectation is of the person providing you the API.

Do you need to know how File.Delete(string) is implemented? How would that change how you utilize the function beyond what was documented for it? What about Interfaces or header files; which give absolutely no implementation details (as is their purpose).

When you impede this process (or make it difficult), this provides poor experience.

For a "Good Developer" this has never been an impediment; even prior to the open sourcing of this project. Microsoft does not obfuscate their code; you could always have looked "under the hood" at the implementation of any of the given classes using any number of the available IL Decompilers.

However, as I have stated before there is nothing to be gleaned from viewing the source to the MSBuild Task that was not better covered in the documentation which at the end of the day is the guarantee from Microsoft.

Good developers also recognize at what layer of abstraction to focus their research time on. Good product owners know where to invest time on features and how to get for what is asked for. Good document writers produce enough documentation such that groveling in the source should be unnecessary.

I do not see any evidence of intellisense being dependent upon (or relying on) an xsd to operate. The article you showed me explains how intellisense operates on an XSD, but it does not say that it requires an xsd to function.

Actually it does; right under the first header:

"After a schema is associated with your document, you get a drop-down list of expected elements any time you type "<" or click the Display an Object Member List button on the XML editor toolbar. For information about how to associate schemas with your XML documents, see XML Document Validation."

Please understand that in this context schema is an XSD (XML Schema Document).

Furthermore, reading the in-lined link (see XML Document Validation) clearly states:

"The XML Editor checks XML 1.0 syntax and also performs data validation as you type. The editor can validate using a document type definition (DTD) or a schema. Red wavy underlines highlight any XML 1.0 well-formed errors. Blue wavy underlines show semantic errors based on DTD or schema validation. Each error has an associated entry in the error list. You can also view the error message by pausing the mouse over the wavy underline."

And even further:

"When editing an XML Schema file, the xsdschema.xsd file located in the schema cache is used for validation. Validation errors are shown as blue wavy underlines. Any compilation errors are also shown with red wavy underlines."

In an MSBuild file this is implicitly loaded by the namespace command:

xmlns="http://schemas.microsoft.com/developer/msbuild/2003"

The exact same way it'd be loaded in for any Xaml or other XML based document format. This is not unique to any of these file formats but is part of the well-defined XML Document Standard.

The article you showed me explains how intellisense operates on an XSD, but it does not say that it requires an xsd to function. Does that make sense? Big difference.

That is a distinction without a difference; however, it is beside the point.

Right, and the tooling that provides for this is not as effective as say what you see in a Xaml-based context.

I'm not sure what you're saying here; I'm not sure how looking at the source of a Task (for example https://github.com/Microsoft/msbuild/blob/c1459f5cbd36f2c33eafc8f4ff087f6ee84c3640/src/XMakeTasks/Move.cs) gives you any insight on how the task (Move) is supposed to be used from within MSBuild; there is no requirement (although it is good practice) that a usage comment is associated with the code that defines the task.

Let’s for a moment say that they implemented what you described; When you were highlighted on a task name that hitting F12 (Go to Definition) took you to either the reference source or a decompiled version of the currently referenced assembly. What would your work flow look like if you were attempting to use the Task (not Debug the task)?

Yikes, this is a very narrow (bordering on close-minded!) view!

This is a view commonly shared by consumers of any API; understanding how the API call is implemented may serve some desire to understand how things work; but it will not explain to you how it should be integrated with other parts of the API to perform useful tasks, nor what the expectation is of the person providing you the API.

Do you need to know how File.Delete(string) is implemented? How would that change how you utilize the function beyond what was documented for it? What about Interfaces or header files; which give absolutely no implementation details (as is their purpose).

When you impede this process (or make it difficult), this provides poor experience.

For a "Good Developer" this has never been an impediment; even prior to the open sourcing of this project. Microsoft does not obfuscate their code; you could always have looked "under the hood" at the implementation of any of the given classes using any number of the available IL Decompilers.

However, as I have stated before there is nothing to be gleaned from viewing the source to the MSBuild Task that was not better covered in the documentation which at the end of the day is the guarantee from Microsoft.

Good developers also recognize at what layer of abstraction to focus their research time on. Good product owners know where to invest time on features and how to get for what is asked for. Good document writers produce enough documentation such that groveling in the source should be unnecessary.

@shederman

This comment has been minimized.

Show comment
Hide comment
@shederman

shederman May 13, 2016

@aolszowka never in a professional environment, by someone who I would consider a professional developer (or Build Master), would I say I've heard a cry for a switch to a JSON based MSBuild.

Hi. I'm a professional developer. I was lead developer on several major projects at a top 20 stock exchange. I was the lead solution architect. I knew MSBuild/Team Build better than most of the Build Masters there and assisted them with developing and debugging their builds. I admit, I don't want a JSON based MSBuild. I want MSBuild gone. It'd be nice if it's simpler replacement was an easier format than XML for humans.

@aolszowka I know the community has had a recent influx of posers from the "DevOps" movement; but there are still the few who actually know what they're doing beyond a drag n' derp interface.

I'm in the DevOps camp, yes. I increased my current client's delivery pace over 100% in one year (with less staff), by adopting DevOps techniques. You know, delivering more value to the business in a shorter time. That's what "professional" software engineers do. Oh wait, I'm a "poser". And I don't know what I'm doing if I don't have a drag n' drop interface. Hmm, where is that IDE? Oh yeah, I don't have one installed. Tough to drag and drop in a text editor dude.

@aolszowka Reading Sayed Ibrahim Hashimi's "Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build" should also be required reading for anyone claiming intimate knowledge.

Read it. Cover to cover. More than once. Years and years ago. And I still rejected MSBuild. So, wait, by your definition I have intimate knowledge. How can I not like MSBuild? Waiting eagerly for the "well, you obviously didn't understand it" response...

@aolszowka Looking at project.json (I had never heard of this project until today)

Wow. You're dismissing other's viewpoints left and right, denigrating their abilities and making snide comments about them being posers, but you don't know the biggest shake up slated for the .NET Core toolchain? Well, until yesterday, that is...

@aolszowka If you're attempting to target an audience that is not using Visual Studio then they should be encouraged to seek out the recommended project system of choice for their environment.

Yeah, I did. It was called project.json. The environment was .NET Core on OSX. But now they're forcing me to use MSBuild, and I don't wanna, 'cause it's rubbish IMO.

@aolszowka The JSON Kids haven't grown up enough yet to understand why such systems are required; it looks like they're starting to come around though based on a quick google search.

"Kids", huh? Haven't grown up enough? Gee whiskers, if you're calling me a kid, I'd love to hear about your professional experience.

Some developers look up from their environment from time to time and evaluate alternatives. They try out Python, or Java, or Maven, or Scala, or F#, or Fake, or SBT, or TypeScript. And they learn. And they improve. And they judge their primary development environment tools based on what they've seen delivering value elsewhere.

Other developers focus on one toolchain and one stack for their entire career, and never learn anything outside their ambit. They think their primary/only development tools are the One True Way™ and there's no point looking at anything else.

Just some friendly career advice: I've found that the second set of developers are always the ones who get retrenched first, and that they never reach the earning potential of the first set of developers. But hey, that's just my experience after two decades years in the field, just a poser kid.

@aolszowka never in a professional environment, by someone who I would consider a professional developer (or Build Master), would I say I've heard a cry for a switch to a JSON based MSBuild.

Hi. I'm a professional developer. I was lead developer on several major projects at a top 20 stock exchange. I was the lead solution architect. I knew MSBuild/Team Build better than most of the Build Masters there and assisted them with developing and debugging their builds. I admit, I don't want a JSON based MSBuild. I want MSBuild gone. It'd be nice if it's simpler replacement was an easier format than XML for humans.

@aolszowka I know the community has had a recent influx of posers from the "DevOps" movement; but there are still the few who actually know what they're doing beyond a drag n' derp interface.

I'm in the DevOps camp, yes. I increased my current client's delivery pace over 100% in one year (with less staff), by adopting DevOps techniques. You know, delivering more value to the business in a shorter time. That's what "professional" software engineers do. Oh wait, I'm a "poser". And I don't know what I'm doing if I don't have a drag n' drop interface. Hmm, where is that IDE? Oh yeah, I don't have one installed. Tough to drag and drop in a text editor dude.

@aolszowka Reading Sayed Ibrahim Hashimi's "Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build" should also be required reading for anyone claiming intimate knowledge.

Read it. Cover to cover. More than once. Years and years ago. And I still rejected MSBuild. So, wait, by your definition I have intimate knowledge. How can I not like MSBuild? Waiting eagerly for the "well, you obviously didn't understand it" response...

@aolszowka Looking at project.json (I had never heard of this project until today)

Wow. You're dismissing other's viewpoints left and right, denigrating their abilities and making snide comments about them being posers, but you don't know the biggest shake up slated for the .NET Core toolchain? Well, until yesterday, that is...

@aolszowka If you're attempting to target an audience that is not using Visual Studio then they should be encouraged to seek out the recommended project system of choice for their environment.

Yeah, I did. It was called project.json. The environment was .NET Core on OSX. But now they're forcing me to use MSBuild, and I don't wanna, 'cause it's rubbish IMO.

@aolszowka The JSON Kids haven't grown up enough yet to understand why such systems are required; it looks like they're starting to come around though based on a quick google search.

"Kids", huh? Haven't grown up enough? Gee whiskers, if you're calling me a kid, I'd love to hear about your professional experience.

Some developers look up from their environment from time to time and evaluate alternatives. They try out Python, or Java, or Maven, or Scala, or F#, or Fake, or SBT, or TypeScript. And they learn. And they improve. And they judge their primary development environment tools based on what they've seen delivering value elsewhere.

Other developers focus on one toolchain and one stack for their entire career, and never learn anything outside their ambit. They think their primary/only development tools are the One True Way™ and there's no point looking at anything else.

Just some friendly career advice: I've found that the second set of developers are always the ones who get retrenched first, and that they never reach the earning potential of the first set of developers. But hey, that's just my experience after two decades years in the field, just a poser kid.

@shederman

This comment has been minimized.

Show comment
Hide comment
@shederman

shederman May 13, 2016

In fact, here's a screen grab of my Online Kindle Reader:

image

In fact, here's a screen grab of my Online Kindle Reader:

image

@aolszowka

This comment has been minimized.

Show comment
Hide comment
@aolszowka

aolszowka May 13, 2016

@shederman

What caused you to Reject MSBuild for your workflows and how do you feel the suggested change will improve MSBuild such that you'd reevaluate it in the future?

@shederman

What caused you to Reject MSBuild for your workflows and how do you feel the suggested change will improve MSBuild such that you'd reevaluate it in the future?

@shederman

This comment has been minimized.

Show comment
Hide comment
@shederman

shederman May 13, 2016

Dude, it was just pain. I could get it working, but very few devs spent the time or cared. So if I set something up in one project, they didn't transfer it to another. If there was a problem, I had to fix it. Even those Build Masters were clueless with a lot of the stuff. From what I could see, they were not in your league by any stretch, I'm a busy guy, I don't have time to chase after build issues.

I just want something that's easily edited by the devs, presented in a familiar and intuitive manner, and doesn't require complex internal knowledge. And I understand property groups, but for imperative-based developers they're counter-intuitive, and an impedance mismatch.

MSBuild uses an inference system to determine what it will do and how it will do it. project.json used a declarative system to describe properties and dependencies. It didn't try and say what should be done, that was up to the toolchain, which knew how to build stuff.

Is that sufficient for a fully fledged build system? No, it's not. But it is sufficient for microservice based architectures in many cases. We have small, simple services, with simple build requirements. Why do we need this inference system to describe the blazingly obvious? Restore packages, build, test, pack.

For the few occasions I needed something sequences, a Powershell or Bash script file did the job just fine. Again, it's not complex stuff. We're not building an operating system. The complexity is in the deployment and management systems, not the build.

So sure, we'll need some sort of task running system at some point. But does it really have to be inference based? The stream based solution of gulps is very intriguing. Maybe not viable for .NET, but an indication of how you can have a task based system with imperative type logic.

Dude, it was just pain. I could get it working, but very few devs spent the time or cared. So if I set something up in one project, they didn't transfer it to another. If there was a problem, I had to fix it. Even those Build Masters were clueless with a lot of the stuff. From what I could see, they were not in your league by any stretch, I'm a busy guy, I don't have time to chase after build issues.

I just want something that's easily edited by the devs, presented in a familiar and intuitive manner, and doesn't require complex internal knowledge. And I understand property groups, but for imperative-based developers they're counter-intuitive, and an impedance mismatch.

MSBuild uses an inference system to determine what it will do and how it will do it. project.json used a declarative system to describe properties and dependencies. It didn't try and say what should be done, that was up to the toolchain, which knew how to build stuff.

Is that sufficient for a fully fledged build system? No, it's not. But it is sufficient for microservice based architectures in many cases. We have small, simple services, with simple build requirements. Why do we need this inference system to describe the blazingly obvious? Restore packages, build, test, pack.

For the few occasions I needed something sequences, a Powershell or Bash script file did the job just fine. Again, it's not complex stuff. We're not building an operating system. The complexity is in the deployment and management systems, not the build.

So sure, we'll need some sort of task running system at some point. But does it really have to be inference based? The stream based solution of gulps is very intriguing. Maybe not viable for .NET, but an indication of how you can have a task based system with imperative type logic.

@aolszowka

This comment has been minimized.

Show comment
Hide comment
@aolszowka

aolszowka May 13, 2016

@shederman

So if I set something up in one project, they didn't transfer it to another.

Is there a reason common includes or pre-defining projects using Visual Studio Templates did not fulfill this need?

doesn't require complex internal knowledge

The devil is always in the details; there is a balance that needs to be struck between flexibility, complexity, and ease of use for developers who are not focused on such tasks I agree. However I thought MSBuild struck a reasonable medium with regards to the requirements placed upon it.

MSBuild uses an inference system to determine what it will do and how it will do it. project.json used a declarative system to describe properties and dependencies. It didn't try and say what should be done, that was up to the toolchain, which knew how to build stuff.

Perhaps as you say I've "never learn anything outside their ambit" but I'm confused as to what you expect the system to do here; at some point you need to declare your dependencies. Could you provide an example of this?

Why do we need this inference system to describe the blazingly obvious?

Because this system is used for more than just simple Microservices; its used to build everything from a Hello World Application to Complex Multi-tiered systems with numerous dependencies and build requirements. The extensibility provided by MSBuild strikes the best balance it can to meet competing needs.

For the few occasions I needed something sequences, a Powershell or Bash script file did the job just fine.

This requires these additional tools to be shipped along side the proposed build system; with MSBuild these can be embedded within the system itself. If your end goal is to reduce the amount of setup an end developer is doing requiring Powershell or Bash to be configured correctly on the system is simply another (easily automated) hurdle.

I did not see a response to the last part of the question; which was how does this suggestion improve MSBuild such that you'd reevaluate it for your purposes?

I'm not here to beat the drum to say that MSBuild meets all needs; its far from a perfect solution for all end users. I am however here to beat the drum against trying to modify it into something it is not; and cannot be without significant investment that results in a fundamental redesign of the product.

At some point it is better to abandon such a product and move on to one that is better suited to address the needs of its developers.

@shederman

So if I set something up in one project, they didn't transfer it to another.

Is there a reason common includes or pre-defining projects using Visual Studio Templates did not fulfill this need?

doesn't require complex internal knowledge

The devil is always in the details; there is a balance that needs to be struck between flexibility, complexity, and ease of use for developers who are not focused on such tasks I agree. However I thought MSBuild struck a reasonable medium with regards to the requirements placed upon it.

MSBuild uses an inference system to determine what it will do and how it will do it. project.json used a declarative system to describe properties and dependencies. It didn't try and say what should be done, that was up to the toolchain, which knew how to build stuff.

Perhaps as you say I've "never learn anything outside their ambit" but I'm confused as to what you expect the system to do here; at some point you need to declare your dependencies. Could you provide an example of this?

Why do we need this inference system to describe the blazingly obvious?

Because this system is used for more than just simple Microservices; its used to build everything from a Hello World Application to Complex Multi-tiered systems with numerous dependencies and build requirements. The extensibility provided by MSBuild strikes the best balance it can to meet competing needs.

For the few occasions I needed something sequences, a Powershell or Bash script file did the job just fine.

This requires these additional tools to be shipped along side the proposed build system; with MSBuild these can be embedded within the system itself. If your end goal is to reduce the amount of setup an end developer is doing requiring Powershell or Bash to be configured correctly on the system is simply another (easily automated) hurdle.

I did not see a response to the last part of the question; which was how does this suggestion improve MSBuild such that you'd reevaluate it for your purposes?

I'm not here to beat the drum to say that MSBuild meets all needs; its far from a perfect solution for all end users. I am however here to beat the drum against trying to modify it into something it is not; and cannot be without significant investment that results in a fundamental redesign of the product.

At some point it is better to abandon such a product and move on to one that is better suited to address the needs of its developers.

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Nov 22, 2016

@MartinJohns I hope you can appreciate the irony as I do of having you declare that there will be 50 flavors of build systems and then state it's never as bad as people make it out to be. 🎆

To be sure here, the idea is to have one CLR-based model that can be described in numerous formats.

Also, I am starting to edge up to @jnm2's challenge here of writing a very simple proof of concept to demonstrate the idea. With as much energy as I have already spent in this repo, I feel like I could have done it in spades times ten now. 😛 I do not want to spend too much time with it for the reason @MaximRouiller states (and more). Let's see where the afternoon gets me (what did I just get myself into now???).

@MartinJohns I hope you can appreciate the irony as I do of having you declare that there will be 50 flavors of build systems and then state it's never as bad as people make it out to be. 🎆

To be sure here, the idea is to have one CLR-based model that can be described in numerous formats.

Also, I am starting to edge up to @jnm2's challenge here of writing a very simple proof of concept to demonstrate the idea. With as much energy as I have already spent in this repo, I feel like I could have done it in spades times ten now. 😛 I do not want to spend too much time with it for the reason @MaximRouiller states (and more). Let's see where the afternoon gets me (what did I just get myself into now???).

@dsplaisted

This comment has been minimized.

Show comment
Hide comment
@dsplaisted

dsplaisted Nov 22, 2016

Member

@MartinJohns

While there are still things I'd like changed (e.g. Version as an attribute instead of an element)

This is happening. You can see here where we are updating the VS project templates to take advantage of this: dotnet/sdk#394 We are also working on further cleanup of the .csproj format.

To @Mike-EEE and others who want to experiment with supporting an entirely different project file format in MSBuild, the place to start looking is probably in the MSBuild Construction APIs. These abstract the underlying XML representation to some degree. They do still reflect the underlying structure of the XML though, so you still have properties inside of PropertyGroups and items inside of ItemGroups, for example.

Member

dsplaisted commented Nov 22, 2016

@MartinJohns

While there are still things I'd like changed (e.g. Version as an attribute instead of an element)

This is happening. You can see here where we are updating the VS project templates to take advantage of this: dotnet/sdk#394 We are also working on further cleanup of the .csproj format.

To @Mike-EEE and others who want to experiment with supporting an entirely different project file format in MSBuild, the place to start looking is probably in the MSBuild Construction APIs. These abstract the underlying XML representation to some degree. They do still reflect the underlying structure of the XML though, so you still have properties inside of PropertyGroups and items inside of ItemGroups, for example.

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Nov 22, 2016

Thank you @dsplaisted for the pointer. We actually found that out earlier in this (now rather lengthy!) thread, when discussing the feasibility of using POCOs vs. XML. XML is indeed tightly coupled to classes throughout the MSBuild libraries, even being used as full properties such as the Project.Xml.

(Can you imagine a Project.Json property? Data should not be tightly coupled to the serialized object it describes. That is what we are aiming to solve.)

To underline the ask here, the idea would be to not introduce a new format, but simply make it so that properties such as Project.Xml go away, and the XML that is read in will simply serialize the Project entity in memory, along with all of its child instances. Hopefully that makes sense.

Once you have this working for one format (XML), then you can make it work for other formats as well. In essence, the project file becomes a serialized Project entity and it can be described in any supported format, and in doing so will yield any tooling magic that is already built for said format.

Thank you @dsplaisted for the pointer. We actually found that out earlier in this (now rather lengthy!) thread, when discussing the feasibility of using POCOs vs. XML. XML is indeed tightly coupled to classes throughout the MSBuild libraries, even being used as full properties such as the Project.Xml.

(Can you imagine a Project.Json property? Data should not be tightly coupled to the serialized object it describes. That is what we are aiming to solve.)

To underline the ask here, the idea would be to not introduce a new format, but simply make it so that properties such as Project.Xml go away, and the XML that is read in will simply serialize the Project entity in memory, along with all of its child instances. Hopefully that makes sense.

Once you have this working for one format (XML), then you can make it work for other formats as well. In essence, the project file becomes a serialized Project entity and it can be described in any supported format, and in doing so will yield any tooling magic that is already built for said format.

@jnm2

This comment has been minimized.

Show comment
Hide comment
@jnm2

jnm2 Nov 22, 2016

Part of this whole thing is that the knowledge of how to build a C# app is in a .targets file which absolutely needs to work with property groups and item groups. Even if you want to serialize the msbuild project 'POCO' as JSON, you'd need JSON versions of item groups and property groups, or else you'd have to abandon msbuild and the C# .targets and write the entire process from scratch.

jnm2 commented Nov 22, 2016

Part of this whole thing is that the knowledge of how to build a C# app is in a .targets file which absolutely needs to work with property groups and item groups. Even if you want to serialize the msbuild project 'POCO' as JSON, you'd need JSON versions of item groups and property groups, or else you'd have to abandon msbuild and the C# .targets and write the entire process from scratch.

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Nov 22, 2016

OK, I took some time to flesh out a SUUUUUUOOOOOPER rough model in what I am thinking here. You can find that here:
https://github.com/Mike-EEE/Stash/tree/master/MsftBuild.Model

I've placed the project POCOs here and the processing POCOs here.

I've described a possible project file here and a possible processing file here. I used @gulshan's template from #1289 as a guide. That's not to say that I followed it completely, however. 👼

The design that I landed on (and am in no way suggesting, just rough-sketching here) makes the Project file a ServiceLocator, so that its "properties" (or services) are not strongly defined, which makes it super flexible. It is up to the processor to pull in the data that it needs (as demonstrated here).

(Again, this is not in any way making a final suggestion in any sense. Just doing some sketching.)

Design discussions/decisions aside, in the end what is important is:

  1. A Project POCO element is defined in a serialized format. (Example)
  2. That Project is then read into memory. (Not defined in this sample)
  3. That Project is then sent to a Processor of some sort. (Example)

I've also described this in Xaml (as you probably know, I am a fan) to also showcase some neat things you could do in this particular format, such as provide a version from an external file, and also use one to query the files needed to compile.

Finally, to showcase the "tooling magic" I keep talking about and the reason I am so Xaml/POCO-crazy, here is a screenshot of the mouse cursor in the minimum logging level of one of the elements:

You can see there's a drop down list, checkboxes, and everything, without having to do anything but simply define a POCO in the Xaml file. This is truly a "lit-up" experience, IMO. Furthermore, in Xaml, there is plugin support for the editors used for the property pane, so we could make it even more customizable/cool if we wanted to. It's this sort of power/paradigm that I think we should strive to achieve -- but in any format possible and not just Xaml.

Hopefully that will clear up my side/position here. But I am sure this will create more questions than not. 😄

OK, I took some time to flesh out a SUUUUUUOOOOOPER rough model in what I am thinking here. You can find that here:
https://github.com/Mike-EEE/Stash/tree/master/MsftBuild.Model

I've placed the project POCOs here and the processing POCOs here.

I've described a possible project file here and a possible processing file here. I used @gulshan's template from #1289 as a guide. That's not to say that I followed it completely, however. 👼

The design that I landed on (and am in no way suggesting, just rough-sketching here) makes the Project file a ServiceLocator, so that its "properties" (or services) are not strongly defined, which makes it super flexible. It is up to the processor to pull in the data that it needs (as demonstrated here).

(Again, this is not in any way making a final suggestion in any sense. Just doing some sketching.)

Design discussions/decisions aside, in the end what is important is:

  1. A Project POCO element is defined in a serialized format. (Example)
  2. That Project is then read into memory. (Not defined in this sample)
  3. That Project is then sent to a Processor of some sort. (Example)

I've also described this in Xaml (as you probably know, I am a fan) to also showcase some neat things you could do in this particular format, such as provide a version from an external file, and also use one to query the files needed to compile.

Finally, to showcase the "tooling magic" I keep talking about and the reason I am so Xaml/POCO-crazy, here is a screenshot of the mouse cursor in the minimum logging level of one of the elements:

You can see there's a drop down list, checkboxes, and everything, without having to do anything but simply define a POCO in the Xaml file. This is truly a "lit-up" experience, IMO. Furthermore, in Xaml, there is plugin support for the editors used for the property pane, so we could make it even more customizable/cool if we wanted to. It's this sort of power/paradigm that I think we should strive to achieve -- but in any format possible and not just Xaml.

Hopefully that will clear up my side/position here. But I am sure this will create more questions than not. 😄

@djanosik

This comment has been minimized.

Show comment
Hide comment
@djanosik

djanosik Nov 22, 2016

@Mike-EEE Too much noise :) The cleared .csproj is much more readable and human friendly. XAML is not the way to go.

djanosik commented Nov 22, 2016

@Mike-EEE Too much noise :) The cleared .csproj is much more readable and human friendly. XAML is not the way to go.

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Nov 22, 2016

Haha @djanosik yes I should have put a disclaimer in there regarding that, as Xaml is definitely more chatty than JSON (or XML). As I mentioned in #1289, there are new flavors of Xaml emerging that address this issue.

The cleared .csproj is much more readable and human friendly.

This is a very subjective statement and really at the heart of the problem we're trying to solve here. Whereas you see Xaml as "less" human friendly, myself and many others love its expressiveness and power.

However, in the end, what is important here is not the verbosity and/or chattiness, but the features and tooling integration that is possible with a POCO-based approach, which Xaml does a great job of doing and I hope that the screenshot and use of MarkupExtensions capture. You simply cannot achieve such power with XML or JSON.

Again, the idea is to eventually capture such concepts and make them available in any format. I use Xaml as of course it does this out of the box without a lot of effort on my part to demonstrate. I'm lazy, what can I say. :)

Mike-EEE commented Nov 22, 2016

Haha @djanosik yes I should have put a disclaimer in there regarding that, as Xaml is definitely more chatty than JSON (or XML). As I mentioned in #1289, there are new flavors of Xaml emerging that address this issue.

The cleared .csproj is much more readable and human friendly.

This is a very subjective statement and really at the heart of the problem we're trying to solve here. Whereas you see Xaml as "less" human friendly, myself and many others love its expressiveness and power.

However, in the end, what is important here is not the verbosity and/or chattiness, but the features and tooling integration that is possible with a POCO-based approach, which Xaml does a great job of doing and I hope that the screenshot and use of MarkupExtensions capture. You simply cannot achieve such power with XML or JSON.

Again, the idea is to eventually capture such concepts and make them available in any format. I use Xaml as of course it does this out of the box without a lot of effort on my part to demonstrate. I'm lazy, what can I say. :)

@jnm2

This comment has been minimized.

Show comment
Hide comment
@jnm2

jnm2 Nov 22, 2016

@Mike-EEE my guess is that you'll interest more people with a project.json-like format reader first, then a csproj-format reader, after that write a XAML one. :-D

jnm2 commented Nov 22, 2016

@Mike-EEE my guess is that you'll interest more people with a project.json-like format reader first, then a csproj-format reader, after that write a XAML one. :-D

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Nov 22, 2016

Haha... OMG I am dying here. OK. I went ahead and made you a Project.json file, @jnm2 and @djanosik:
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/MsftBuild.SampleProject/Project.json

(And I did this by simply newing up the Xaml-described POCO and serializing it in a JSON-based format, which is a piece of cake since we are dealing with a POCO.)

So again: It's not the chattiness or (theoretical) schema that is used here that is important. What IS important is that this file and this file both describe this POCO. Make sense?

Mike-EEE commented Nov 22, 2016

Haha... OMG I am dying here. OK. I went ahead and made you a Project.json file, @jnm2 and @djanosik:
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/MsftBuild.SampleProject/Project.json

(And I did this by simply newing up the Xaml-described POCO and serializing it in a JSON-based format, which is a piece of cake since we are dealing with a POCO.)

So again: It's not the chattiness or (theoretical) schema that is used here that is important. What IS important is that this file and this file both describe this POCO. Make sense?

@djanosik

This comment has been minimized.

Show comment
Hide comment
@djanosik

djanosik Nov 22, 2016

@Mike-EEE It makes sense. How would you create custom build tasks (preferably without referencing other assemblies)? Or do you want to completely separate project metadata and build script?

@Mike-EEE It makes sense. How would you create custom build tasks (preferably without referencing other assemblies)? Or do you want to completely separate project metadata and build script?

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Nov 22, 2016

Ah now @djanosik you're proving that the reward for hard work is more hard work. :) In this case, we are tackling a few items here. This actually started out over @ #1289 when @jnm2 rightly reminded me from a discussion in aspnet/Home#1433 that processing should be separate from data. So this POC is really showing off two things:

  1. POCO-based modeling
  2. Separation of concerns between processing and data/definition.

Now, to answer your question, creating a new custom build task would be similar to implementing ITask as I have done for the BuildProcessor here. In this case, the BuildProcessor doesn't have any properties, but if it did, it would be described/defined in the Processor definition file.

Again, this is simply a sketched idea, and nothing definitive/authoritative, to help flesh out the idea of what I am interested in solving.

Ah now @djanosik you're proving that the reward for hard work is more hard work. :) In this case, we are tackling a few items here. This actually started out over @ #1289 when @jnm2 rightly reminded me from a discussion in aspnet/Home#1433 that processing should be separate from data. So this POC is really showing off two things:

  1. POCO-based modeling
  2. Separation of concerns between processing and data/definition.

Now, to answer your question, creating a new custom build task would be similar to implementing ITask as I have done for the BuildProcessor here. In this case, the BuildProcessor doesn't have any properties, but if it did, it would be described/defined in the Processor definition file.

Again, this is simply a sketched idea, and nothing definitive/authoritative, to help flesh out the idea of what I am interested in solving.

@slorion

This comment has been minimized.

Show comment
Hide comment
@slorion

slorion Nov 23, 2016

Reading this thread, it's as if Gradle and HOCON don't exist ... I don't mean that as trolling, just wondering why there is not even a mention of those since truthfully, they are a joy to use. HOCON is already there: http://getakka.net/docs/concepts/hocon. Now waiting for a Gradle plugin for .NET :)

slorion commented Nov 23, 2016

Reading this thread, it's as if Gradle and HOCON don't exist ... I don't mean that as trolling, just wondering why there is not even a mention of those since truthfully, they are a joy to use. HOCON is already there: http://getakka.net/docs/concepts/hocon. Now waiting for a Gradle plugin for .NET :)

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Nov 23, 2016

Indeed @slorion, Gradle is very much a driving force behind #1289, Check it out and make sure you upvote it and/or share your feedback. I was not familiar with HOCON until you mentioned it here. Thank you for sharing. The idea here is to be able to support any format as long as there is a serializer for it. So if HOCON has serializers, then it will be possible to tie into it as well. :)

Indeed @slorion, Gradle is very much a driving force behind #1289, Check it out and make sure you upvote it and/or share your feedback. I was not familiar with HOCON until you mentioned it here. Thank you for sharing. The idea here is to be able to support any format as long as there is a serializer for it. So if HOCON has serializers, then it will be possible to tie into it as well. :)

@slorion

This comment has been minimized.

Show comment
Hide comment
@slorion

slorion Nov 23, 2016

Ah thanks, glad there is some push for that idea.

I was mentioning HOCON because I saw some comments about web/app.config which are also a pain to deal with, especially when deploying to multiple targets with some specific configuration.

slorion commented Nov 23, 2016

Ah thanks, glad there is some push for that idea.

I was mentioning HOCON because I saw some comments about web/app.config which are also a pain to deal with, especially when deploying to multiple targets with some specific configuration.

@Mike-EEE Mike-EEE referenced this issue in aL3891/CustomPackageReferences Dec 7, 2016

Closed

Consider Using Surrogates (POCOs) Rather Than DOM Elements #1

@Mike-EEE Mike-EEE referenced this issue Dec 19, 2016

Closed

MSBuild 15 Sdk Design #1493

0 of 13 tasks complete
@qqbuby

This comment has been minimized.

Show comment
Hide comment
@qqbuby

qqbuby Jan 15, 2017

I write C#.NET 6+ years, I hate the .csproj(.xml format file). And I have use .NET Core from DNX RC1 to .NET Core 1.1. The project.json is big forward step. Were you thinking of our feedback ? And if you (.NET Core MS dev team) are insist to give up project.json, I will give up .NET (Core).

qqbuby commented Jan 15, 2017

I write C#.NET 6+ years, I hate the .csproj(.xml format file). And I have use .NET Core from DNX RC1 to .NET Core 1.1. The project.json is big forward step. Were you thinking of our feedback ? And if you (.NET Core MS dev team) are insist to give up project.json, I will give up .NET (Core).

@grbd

This comment has been minimized.

Show comment
Hide comment
@grbd

grbd Jan 16, 2017

Just as a simple idea, if .Net core needs to switch across to using .csproj files for the IDE
and the only way to make changes to it without the ide is via a tool (which sounds kind of horrible)

Why not have a tool / something part of the dotnet tool that reads in a project.json file and outputs the .csproj file as part of the build process
so instead of project.json.lock which is sort of a postbuild version of project.json, it outputs directly to a .csproj file instead

It's a bit of extra work but it's probably worth while

grbd commented Jan 16, 2017

Just as a simple idea, if .Net core needs to switch across to using .csproj files for the IDE
and the only way to make changes to it without the ide is via a tool (which sounds kind of horrible)

Why not have a tool / something part of the dotnet tool that reads in a project.json file and outputs the .csproj file as part of the build process
so instead of project.json.lock which is sort of a postbuild version of project.json, it outputs directly to a .csproj file instead

It's a bit of extra work but it's probably worth while

@jnm2

This comment has been minimized.

Show comment
Hide comment
@jnm2

jnm2 Jan 16, 2017

I don't want to dampen the enthusiasm for further thinking outside the box, but the new .csproj is a brilliant solution so far.

[Downvotes: 😆]

jnm2 commented Jan 16, 2017

I don't want to dampen the enthusiasm for further thinking outside the box, but the new .csproj is a brilliant solution so far.

[Downvotes: 😆]

@Bartmax

This comment has been minimized.

Show comment
Hide comment
@Bartmax

Bartmax Jan 18, 2017

All I see is people arguing about the json format just because they never used it and because it knows msbuild from top to bottom.

<NuGetPack File="%(NSPSTransformed.Identity)" OutputDirectory="$(BuildOutputNuGet)" Properties="Configuration=Release" IncludeReferencedProjects="true" ToolPath="$(nugetToolPath)" />

Anyone is really comparing that 💩 to project.json ?

All I see in every csproj file suggested, posted, and called fabulous intelisense is full of magic strings even for stuff like True and False.

Ironically, feels like CSPROJ is not typed while JSON is typed.

on project.json side:
some smart people realized that this would be a great format for asp.net core. Even Fowler said it was it's favorite feature.
It's not about the format or the intelisense or feature A and B. it's about a whole experience.
It's typed, got intelisense, got http request options, was very fast, very understandable, super ultra duper hyper dicoverable, and if you think csproj also is, you didn't USED it, and just commenting based on looking at the file on some github repo.

If you are going against it, let us know that you used it and tried for a least a week.

but
apparently, it has some limitations that aren't present on csproj. (and this might be a very good/valid reason to drop it's support of right now)

I'm all supportive to the csproj and I trust people behind the product.
Just, give some credit and ask yourselves "why, if project.json is no good than csproj, the smart people behind asp.net invest and make a system that everyone (that used it) fall in love at first sight?"

Imports? Targets? Properties? ToolPath? those words are all meaningless and that's why you don't see it mentioned on project.json at all, while target framework, dependencies, includes (which tooltips suggesting that supports globbing patters, a string or an array of strings inside a publishOptions are very self explanatory.

conclusion: project.json is A-MA-ZING. period. If you don't think it is, you didn't used it. It's not about the file format but for a lot of subtle thing that became with the "experience". Stop comparing it via file diff. just pick a project and start developing.

True fact: When project.json was first introduced, it had no documentation, no answer on stack overflow, no real help from the IDE, still all web developers were editing it by hand and were very happy.
Now in csproj, we have docs, lot of history, a 1.1 stable product, experts around the globe, and yet web developers are using a less-productive GUI to make changes to the project file and aren't any happy with csproj.

To all project.json haters: try it. and point exactly what's flawed or bad about it.
To all msbuild lovers: sorry, there is better stuff out there, even if it means you need to change/adapt.
To all project.json lovers: it has limitations and associated costs. Deal with it, having one thing is best overall, and you can still dream of a better future.
to all msbuild haters: be vocal about your pain points. chances are (at least have some faith) it will evolve to something useful as project.json was, not today... but it might happen.

Bartmax commented Jan 18, 2017

All I see is people arguing about the json format just because they never used it and because it knows msbuild from top to bottom.

<NuGetPack File="%(NSPSTransformed.Identity)" OutputDirectory="$(BuildOutputNuGet)" Properties="Configuration=Release" IncludeReferencedProjects="true" ToolPath="$(nugetToolPath)" />

Anyone is really comparing that 💩 to project.json ?

All I see in every csproj file suggested, posted, and called fabulous intelisense is full of magic strings even for stuff like True and False.

Ironically, feels like CSPROJ is not typed while JSON is typed.

on project.json side:
some smart people realized that this would be a great format for asp.net core. Even Fowler said it was it's favorite feature.
It's not about the format or the intelisense or feature A and B. it's about a whole experience.
It's typed, got intelisense, got http request options, was very fast, very understandable, super ultra duper hyper dicoverable, and if you think csproj also is, you didn't USED it, and just commenting based on looking at the file on some github repo.

If you are going against it, let us know that you used it and tried for a least a week.

but
apparently, it has some limitations that aren't present on csproj. (and this might be a very good/valid reason to drop it's support of right now)

I'm all supportive to the csproj and I trust people behind the product.
Just, give some credit and ask yourselves "why, if project.json is no good than csproj, the smart people behind asp.net invest and make a system that everyone (that used it) fall in love at first sight?"

Imports? Targets? Properties? ToolPath? those words are all meaningless and that's why you don't see it mentioned on project.json at all, while target framework, dependencies, includes (which tooltips suggesting that supports globbing patters, a string or an array of strings inside a publishOptions are very self explanatory.

conclusion: project.json is A-MA-ZING. period. If you don't think it is, you didn't used it. It's not about the file format but for a lot of subtle thing that became with the "experience". Stop comparing it via file diff. just pick a project and start developing.

True fact: When project.json was first introduced, it had no documentation, no answer on stack overflow, no real help from the IDE, still all web developers were editing it by hand and were very happy.
Now in csproj, we have docs, lot of history, a 1.1 stable product, experts around the globe, and yet web developers are using a less-productive GUI to make changes to the project file and aren't any happy with csproj.

To all project.json haters: try it. and point exactly what's flawed or bad about it.
To all msbuild lovers: sorry, there is better stuff out there, even if it means you need to change/adapt.
To all project.json lovers: it has limitations and associated costs. Deal with it, having one thing is best overall, and you can still dream of a better future.
to all msbuild haters: be vocal about your pain points. chances are (at least have some faith) it will evolve to something useful as project.json was, not today... but it might happen.

@gulshan

This comment has been minimized.

Show comment
Hide comment
@gulshan

gulshan Jan 24, 2017

Proposed a .net object notation format based on object, collection and index initializers here- dotnet/roslyn#16648
Please have a look. I deliberately used a project description for example. 😄

gulshan commented Jan 24, 2017

Proposed a .net object notation format based on object, collection and index initializers here- dotnet/roslyn#16648
Please have a look. I deliberately used a project description for example. 😄

@Mike-EEE Mike-EEE referenced this issue in wojtpl2/ExtendedXmlSerializer Feb 7, 2017

Merged

Feature/arrays #46

@AlgorithmsAreCool

This comment has been minimized.

Show comment
Hide comment
@AlgorithmsAreCool

AlgorithmsAreCool Feb 7, 2017

I think @jnm2 is right. As much as I complained about the move back to XML, I can now see that it was a communication problem. The CLI/MsBuild team told us "trust us it will be great" but they didn't provide examples or ever update the docs.

IMHO the new csproj is GREAT. I'm having an easier time with it than with the json syntax honestly.

Here are two (names masked) csproj files i am compiling today (in VS2017 RC3).

  • I am developing in VSCode and VS2017 interchangeably and at the same time
  • I am running via F5 (debugging) and from dotnet run.
  • I am debugging and using Edit+Continue
  • I am hand editing the project file and VS2017 is updating in realtime.
  • I am generating platform specific executables via dotnet publish -r win7-x86 at others
  • Dozens of .cs files, thousands of lines.
  • No GUIDS
  • No crazy conditions

Library (MyCorp.Lib.csproj)

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard1.6</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" Version="9.0.2-beta2" />
    <PackageReference Include="protobuf-net" Version="2.1.0" />
    <PackageReference Include="System.Diagnostics.Process" Version="4.3.0" />
    <PackageReference Include="System.IO.MemoryMappedFiles" Version="4.3.0" />
    <PackageReference Include="System.IO.Pipes" Version="4.3.0" />
    <PackageReference Include="System.Runtime.Loader" Version="4.3.0" />
    <PackageReference Include="System.ServiceProcess.ServiceController" Version="4.3.0" />
    <PackageReference Include="System.Threading.Tasks.Dataflow" Version="4.7.0" />
    <PackageReference Include="System.Threading.Thread" Version="4.3.0" />
  </ItemGroup>
</Project>

Executable (MyCorp.Connector.Runner.csporj)

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp1.0</TargetFramework>
    <AssemblyName>MyCorp.Connector.Runner</AssemblyName>
    <OutputType>Exe</OutputType>
  </PropertyGroup>
  <ItemGroup>
    <ProjectReference Include="..\..\Lib\MyCorp.Lib.csproj" />
    <ProjectReference Include="..\..\WebStuff\MyCorp.WebStuff.csproj" />
    <ProjectReference Include="..\..\Connector.Common\MyCorp.Connector.Common.csproj" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="protobuf-net" Version="2.1.0" />
    <PackageReference Include="Microsoft.Extensions.CommandLineUtils" Version="1.1.0" />
    <PackageReference Include="System.ValueTuple" Version="4.3.0" />
  </ItemGroup>
</Project>

I think we should all take a step back and look at the current progress of the simplification effort and decide if it is good enough now, because I think that it is.

It's working people.

I think @jnm2 is right. As much as I complained about the move back to XML, I can now see that it was a communication problem. The CLI/MsBuild team told us "trust us it will be great" but they didn't provide examples or ever update the docs.

IMHO the new csproj is GREAT. I'm having an easier time with it than with the json syntax honestly.

Here are two (names masked) csproj files i am compiling today (in VS2017 RC3).

  • I am developing in VSCode and VS2017 interchangeably and at the same time
  • I am running via F5 (debugging) and from dotnet run.
  • I am debugging and using Edit+Continue
  • I am hand editing the project file and VS2017 is updating in realtime.
  • I am generating platform specific executables via dotnet publish -r win7-x86 at others
  • Dozens of .cs files, thousands of lines.
  • No GUIDS
  • No crazy conditions

Library (MyCorp.Lib.csproj)

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard1.6</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" Version="9.0.2-beta2" />
    <PackageReference Include="protobuf-net" Version="2.1.0" />
    <PackageReference Include="System.Diagnostics.Process" Version="4.3.0" />
    <PackageReference Include="System.IO.MemoryMappedFiles" Version="4.3.0" />
    <PackageReference Include="System.IO.Pipes" Version="4.3.0" />
    <PackageReference Include="System.Runtime.Loader" Version="4.3.0" />
    <PackageReference Include="System.ServiceProcess.ServiceController" Version="4.3.0" />
    <PackageReference Include="System.Threading.Tasks.Dataflow" Version="4.7.0" />
    <PackageReference Include="System.Threading.Thread" Version="4.3.0" />
  </ItemGroup>
</Project>

Executable (MyCorp.Connector.Runner.csporj)

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp1.0</TargetFramework>
    <AssemblyName>MyCorp.Connector.Runner</AssemblyName>
    <OutputType>Exe</OutputType>
  </PropertyGroup>
  <ItemGroup>
    <ProjectReference Include="..\..\Lib\MyCorp.Lib.csproj" />
    <ProjectReference Include="..\..\WebStuff\MyCorp.WebStuff.csproj" />
    <ProjectReference Include="..\..\Connector.Common\MyCorp.Connector.Common.csproj" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="protobuf-net" Version="2.1.0" />
    <PackageReference Include="Microsoft.Extensions.CommandLineUtils" Version="1.1.0" />
    <PackageReference Include="System.ValueTuple" Version="4.3.0" />
  </ItemGroup>
</Project>

I think we should all take a step back and look at the current progress of the simplification effort and decide if it is good enough now, because I think that it is.

It's working people.

@davkean

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean Feb 8, 2017

Member

@AlgorithmsAreCool Thanks a lot for the feedback, I'm glad you are happy with the progress we've made. If I look back from when we announced that we were moving from project.json -> csproj to now, we've added a lot over the old csproj:

Project:

  • Smart defaults. AssemblyName, Default Namespace, etc now have sensible defaults and don't need to be specified by default.
  • No more GUIDs. :)
  • Implicit language-specific/target-specific props/targets via the Sdk attribute
  • Metadata as attributes, so you can say <PackageReference Include="Newtonsoft.Json" Version="9.0.1"/> instead of <PackageReference Include="Newtonsoft.Json"><Version>9.0.1</Version></PackageReference. This works with all items not just package references.
  • Implicit configurations - by default all projects have two configurations; Debug|AnyCPU and Release|AnyCPU with sensible defaults. (Note: We currently have 6 configs in the RC, but 2 by time we ship).
  • Implicit globbing support, with a default set of common globs so you don't need to specify them. Projects can override if they'd like
  • Simplified project references, no need to specify the Name or GUID metadata
  • Auto-generate AssemblyInfo, including <AssemblyVersion> and <AssemblyFileVersion> so that these can now be based on MSBuild properties.
  • Transitive project references

Targeting:

  • Friendly TFM names in <TargetFramework>, so you don't need to specify <TargetFrameworkIdentifier> or <TargetFrameworkVersion>.
  • Multi-targeting support via the <TargetFrameworks> property, so that a single project can produce multiple outputs targeting multiple frameworks/platforms
  • Implicit conditional compilation symbols based on the target framework you target
  • Support for conditional items such as references, packages, and compile items and have VS respect them, so you can differ them based on target framework.

NuGet:

  • <PackageReference /> which enables you specify (just) your top-level package dependencies inside csproj along with your other dependencies
  • Transitive package references
  • NuGet Restore via msbuild
  • Produce a NuGet package via msbuild
  • Background restore, so packages are restored in the background while the project is open.

Visual Studio:

  • Real support for globbing (**\*.cs, etc) - no longer does VS expand the glob when you delete a file, or add an include when you add a file already included in the glob. VS also automatically picks up addition of new files (or deletions of existing files) automatically.
  • Auto refresh. VS will automatically pick up changes from disk when you switch branches or modify it another editor and just apply the differences without reloading the project
  • Edit while open. You can now edit the project file while the project is open, and have VS pick up the changes on Save.
  • New Dependency node (replacement for references) that shows packages, references, project references, SDKs and their dependencies.

Above is just the list that I can remember off the top of my head, I'm sure I've missed a bunch. Anyway, we've been on a journey that will continue long past this release. Please keep the feedback coming!

Member

davkean commented Feb 8, 2017

@AlgorithmsAreCool Thanks a lot for the feedback, I'm glad you are happy with the progress we've made. If I look back from when we announced that we were moving from project.json -> csproj to now, we've added a lot over the old csproj:

Project:

  • Smart defaults. AssemblyName, Default Namespace, etc now have sensible defaults and don't need to be specified by default.
  • No more GUIDs. :)
  • Implicit language-specific/target-specific props/targets via the Sdk attribute
  • Metadata as attributes, so you can say <PackageReference Include="Newtonsoft.Json" Version="9.0.1"/> instead of <PackageReference Include="Newtonsoft.Json"><Version>9.0.1</Version></PackageReference. This works with all items not just package references.
  • Implicit configurations - by default all projects have two configurations; Debug|AnyCPU and Release|AnyCPU with sensible defaults. (Note: We currently have 6 configs in the RC, but 2 by time we ship).
  • Implicit globbing support, with a default set of common globs so you don't need to specify them. Projects can override if they'd like
  • Simplified project references, no need to specify the Name or GUID metadata
  • Auto-generate AssemblyInfo, including <AssemblyVersion> and <AssemblyFileVersion> so that these can now be based on MSBuild properties.
  • Transitive project references

Targeting:

  • Friendly TFM names in <TargetFramework>, so you don't need to specify <TargetFrameworkIdentifier> or <TargetFrameworkVersion>.
  • Multi-targeting support via the <TargetFrameworks> property, so that a single project can produce multiple outputs targeting multiple frameworks/platforms
  • Implicit conditional compilation symbols based on the target framework you target
  • Support for conditional items such as references, packages, and compile items and have VS respect them, so you can differ them based on target framework.

NuGet:

  • <PackageReference /> which enables you specify (just) your top-level package dependencies inside csproj along with your other dependencies
  • Transitive package references
  • NuGet Restore via msbuild
  • Produce a NuGet package via msbuild
  • Background restore, so packages are restored in the background while the project is open.

Visual Studio:

  • Real support for globbing (**\*.cs, etc) - no longer does VS expand the glob when you delete a file, or add an include when you add a file already included in the glob. VS also automatically picks up addition of new files (or deletions of existing files) automatically.
  • Auto refresh. VS will automatically pick up changes from disk when you switch branches or modify it another editor and just apply the differences without reloading the project
  • Edit while open. You can now edit the project file while the project is open, and have VS pick up the changes on Save.
  • New Dependency node (replacement for references) that shows packages, references, project references, SDKs and their dependencies.

Above is just the list that I can remember off the top of my head, I'm sure I've missed a bunch. Anyway, we've been on a journey that will continue long past this release. Please keep the feedback coming!

@slorion

This comment has been minimized.

Show comment
Hide comment
@slorion

slorion Feb 8, 2017

@davkean That is indeed a very big improvement syntax wise! That said, the real problems arise when a build requires more than simply declaring dependencies and conforming to standard .NET toolset. This is where Gradle shines and I still wonder why it is not used at least as a source of inspiration/lessons learned. This project format looks like Maven pom.xml with a much better syntax, which is nice, but there is a reason why Gradle or SBT were created.

slorion commented Feb 8, 2017

@davkean That is indeed a very big improvement syntax wise! That said, the real problems arise when a build requires more than simply declaring dependencies and conforming to standard .NET toolset. This is where Gradle shines and I still wonder why it is not used at least as a source of inspiration/lessons learned. This project format looks like Maven pom.xml with a much better syntax, which is nice, but there is a reason why Gradle or SBT were created.

@xoofx

This comment has been minimized.

Show comment
Hide comment
@xoofx

xoofx Feb 8, 2017

That said, the real problems arise when a build requires more than simply declaring dependencies and conforming to standard .NET toolset. This is where Gradle shines

@slorion What do you mean? The new clean csproj is built on msbuild which is a full build system. I don't know much about Gradle, but in terms of build system, you can do pretty much whatever you want with msbuild and develop complex builds. That's one of the reasons they switched back from project.json to (clean) msbuild projects.

[Edit]The real next step is to replace *.sln with a proper clean msbuild solution file to coordinate the build of multiple projects (and this is actually what is done as a sln is already converted to a msbuild file under the hood..) but I believe that they will bring this change at some point after the project.json migration[/Edit]

xoofx commented Feb 8, 2017

That said, the real problems arise when a build requires more than simply declaring dependencies and conforming to standard .NET toolset. This is where Gradle shines

@slorion What do you mean? The new clean csproj is built on msbuild which is a full build system. I don't know much about Gradle, but in terms of build system, you can do pretty much whatever you want with msbuild and develop complex builds. That's one of the reasons they switched back from project.json to (clean) msbuild projects.

[Edit]The real next step is to replace *.sln with a proper clean msbuild solution file to coordinate the build of multiple projects (and this is actually what is done as a sln is already converted to a msbuild file under the hood..) but I believe that they will bring this change at some point after the project.json migration[/Edit]

@slorion

This comment has been minimized.

Show comment
Hide comment
@slorion

slorion Feb 8, 2017

@xoofx What I meant is that once you get past simple builds, you need to get into the innards of msbuild. For having done that in the past, I cannot say it is a pleasing experience to say the least. At least now, merging csproj files will not be such a pain.

slorion commented Feb 8, 2017

@xoofx What I meant is that once you get past simple builds, you need to get into the innards of msbuild. For having done that in the past, I cannot say it is a pleasing experience to say the least. At least now, merging csproj files will not be such a pain.

@xoofx

This comment has been minimized.

Show comment
Hide comment
@xoofx

xoofx Feb 8, 2017

@slorion I see your concern, so yes, the msbuild syntax sucks and I would not mind switching to a more simpler DSL + curly braced syntax (e.g ala Graddle)... but one step at a time... 😉

xoofx commented Feb 8, 2017

@slorion I see your concern, so yes, the msbuild syntax sucks and I would not mind switching to a more simpler DSL + curly braced syntax (e.g ala Graddle)... but one step at a time... 😉

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Feb 8, 2017

👍 to the great work of the new .csproj format. @davkean and team have been impressively busy and productive over in the CPS repo and they have been a marvel to watch. The new format is remarkable and nothing less than impressive. (But as @xoofx suggests, it's high-time to apply that magic to the arcane and cryptic .sln file. 😉)

Along such lines, that is not to say that we still cannot make great improvements to the IDE to further the goal here. In my mind, the goal of the issue is to create an experience that allows:

  • Viewable in a desired data format (much like how .NET developers can choose to work in C#/VB/F#)
  • Can hand-edit like a champ (seems like this is closer to reality now ala above)
  • Visual/designer-tooling friendly (sort of the initial driver here)

There are two camps here: those that enjoy the CLI and ... those who don't. :) Both of these camps should be considered going forward to create a successful development paradigm.

The purpose of using a POCO-based development scheme is that the schema is automatically generated for you from the class definitions, and designer tooling automatically "lights up" when directed towards it. It makes it easier for both developer and tooling to use for development.

However, I am definitely open to any other innovative ideas and directions to accomplish this goal. I really enjoy reading @gulshan's thoughts and efforts in the different threads for a different object notation. Gradle seems to be the super hot cake right now, so maybe there might be something worth learning and integrating there. Maybe some cross between its format and a visual tooling integration of @ionoy's great work with AmmyUI (imagine working with a VS/MSBuild file but with monster intellisense on steroids) is the answer? To be continued. :)

Mike-EEE commented Feb 8, 2017

👍 to the great work of the new .csproj format. @davkean and team have been impressively busy and productive over in the CPS repo and they have been a marvel to watch. The new format is remarkable and nothing less than impressive. (But as @xoofx suggests, it's high-time to apply that magic to the arcane and cryptic .sln file. 😉)

Along such lines, that is not to say that we still cannot make great improvements to the IDE to further the goal here. In my mind, the goal of the issue is to create an experience that allows:

  • Viewable in a desired data format (much like how .NET developers can choose to work in C#/VB/F#)
  • Can hand-edit like a champ (seems like this is closer to reality now ala above)
  • Visual/designer-tooling friendly (sort of the initial driver here)

There are two camps here: those that enjoy the CLI and ... those who don't. :) Both of these camps should be considered going forward to create a successful development paradigm.

The purpose of using a POCO-based development scheme is that the schema is automatically generated for you from the class definitions, and designer tooling automatically "lights up" when directed towards it. It makes it easier for both developer and tooling to use for development.

However, I am definitely open to any other innovative ideas and directions to accomplish this goal. I really enjoy reading @gulshan's thoughts and efforts in the different threads for a different object notation. Gradle seems to be the super hot cake right now, so maybe there might be something worth learning and integrating there. Maybe some cross between its format and a visual tooling integration of @ionoy's great work with AmmyUI (imagine working with a VS/MSBuild file but with monster intellisense on steroids) is the answer? To be continued. :)

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 25, 2017

I'm new to C# and .NET in general. Hearing about Core made me excited to learn C#. I booted up VS2015 and created a solution. I immediately felt at home, and things like project.json definitely contributed to that feeling.

I'm not the kind of developer who stays in their comfort zone. You know the type: too lazy/afraid to learn something new. Still, glancing at .csproj files makes my brain cells commit seppuku. Looking through the patch notes though, I must say the team has made some nice improvements.

If MSBuild support entices people to migrate legacy projects thus contributing to the future success of the platform, then I can get on board with it. But what if the cost of that is scaring away new developers? It's just one of those things that makes me think, "There must be a better way". As a padawan I can't say I know the way, but even a padawan can share their perspective and insight.

Luke: Master, moving stones around is one thing. This is totally different.
Yoda: No! No different! Only different in your mind. You must unlearn what you have learned.
Luke: All right, I'll give it a try.

ghost commented Feb 25, 2017

I'm new to C# and .NET in general. Hearing about Core made me excited to learn C#. I booted up VS2015 and created a solution. I immediately felt at home, and things like project.json definitely contributed to that feeling.

I'm not the kind of developer who stays in their comfort zone. You know the type: too lazy/afraid to learn something new. Still, glancing at .csproj files makes my brain cells commit seppuku. Looking through the patch notes though, I must say the team has made some nice improvements.

If MSBuild support entices people to migrate legacy projects thus contributing to the future success of the platform, then I can get on board with it. But what if the cost of that is scaring away new developers? It's just one of those things that makes me think, "There must be a better way". As a padawan I can't say I know the way, but even a padawan can share their perspective and insight.

Luke: Master, moving stones around is one thing. This is totally different.
Yoda: No! No different! Only different in your mind. You must unlearn what you have learned.
Luke: All right, I'll give it a try.

@garywoodfine

This comment has been minimized.

Show comment
Hide comment
@garywoodfine

garywoodfine Feb 27, 2017

I think the downside, is that on the whole VS studio is too opinionated either way. I have been a .net developer since .net 1.0 back in 2003. I have always hated MSBuild probably mostly because in my mind it is so closely aligned with the worst of Microsoft known as TFS. I have always preferred what was known as the ALT.net stack of the day. That's not say that there haven't been great products in the .net stack as whole. Probably most Devs have a Love/Hate relationship with VS Studio, just like most Java Devs have a love/hate relationship with Eclipse or IntelliJ.

Personally I think this is very clearly portrayed in the comments above, there certainly isn't the ONE right way. Honestly whichever way the decision went, there were going to be losers. Yet another Brexit/Trump choice!

I did really like the Project.json format. Found it very simple to grok and was easy to hand edit.
But saying that on the whole, I do like the new csproj format,

What I don't like and specifically the issue I have now, is that I am working in VS 2017 RC, we're just a couple of days away from being released, and some basic things just aren't working. Which are a direct result of json/csproj shift, and have had a direct impact on my productivity.

I'm used to working with OS products, and understand the risks of developing new software on release candidates stuff, but when a notifications goes out a few weeks ago, warning of the change, and steps to take to prepare for it. But yet things just don't work

dotnet ef
System.IO.FileNotFoundException: Could not find file 'C:\Users\gary\code\portal\src\DBDummyUI\project.json'.
File name: 'C:\Users\gary\code\portal\src\DBDummyUI\project.json'

I have had to basically read the internet cover to cover to only find this post
https://github.com/aspnet/Tooling/blob/master/known-issues-vs2017.md

Which kinda informs me that EFcore tooling will not work with the new csproj format. Yet, we're still only days away from a release.

It's not a moan, on the team or Microsoft. I know at the end of the day, it was always going to be a hobsons choice. However, I do think there is a lot of scope in the argument of giving the community the choice of format, instead of giving them an opinionated implementation, based on the fact that it works with MSbuild, which is ok if you're going to use MSBUILD but what if you're not ?

Apologies for the long ramble!

I think the downside, is that on the whole VS studio is too opinionated either way. I have been a .net developer since .net 1.0 back in 2003. I have always hated MSBuild probably mostly because in my mind it is so closely aligned with the worst of Microsoft known as TFS. I have always preferred what was known as the ALT.net stack of the day. That's not say that there haven't been great products in the .net stack as whole. Probably most Devs have a Love/Hate relationship with VS Studio, just like most Java Devs have a love/hate relationship with Eclipse or IntelliJ.

Personally I think this is very clearly portrayed in the comments above, there certainly isn't the ONE right way. Honestly whichever way the decision went, there were going to be losers. Yet another Brexit/Trump choice!

I did really like the Project.json format. Found it very simple to grok and was easy to hand edit.
But saying that on the whole, I do like the new csproj format,

What I don't like and specifically the issue I have now, is that I am working in VS 2017 RC, we're just a couple of days away from being released, and some basic things just aren't working. Which are a direct result of json/csproj shift, and have had a direct impact on my productivity.

I'm used to working with OS products, and understand the risks of developing new software on release candidates stuff, but when a notifications goes out a few weeks ago, warning of the change, and steps to take to prepare for it. But yet things just don't work

dotnet ef
System.IO.FileNotFoundException: Could not find file 'C:\Users\gary\code\portal\src\DBDummyUI\project.json'.
File name: 'C:\Users\gary\code\portal\src\DBDummyUI\project.json'

I have had to basically read the internet cover to cover to only find this post
https://github.com/aspnet/Tooling/blob/master/known-issues-vs2017.md

Which kinda informs me that EFcore tooling will not work with the new csproj format. Yet, we're still only days away from a release.

It's not a moan, on the team or Microsoft. I know at the end of the day, it was always going to be a hobsons choice. However, I do think there is a lot of scope in the argument of giving the community the choice of format, instead of giving them an opinionated implementation, based on the fact that it works with MSbuild, which is ok if you're going to use MSBUILD but what if you're not ?

Apologies for the long ramble!

@dasMulli

This comment has been minimized.

Show comment
Hide comment
@dasMulli

dasMulli Feb 28, 2017

Contributor

@garywoodfine you might be missing a reference to the msbuld version of the ef tools in your csproj (note the version number):

<ItemGroup>
  <DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.0-msbuild3-final" />
</ItemGroup>
Contributor

dasMulli commented Feb 28, 2017

@garywoodfine you might be missing a reference to the msbuld version of the ef tools in your csproj (note the version number):

<ItemGroup>
  <DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.0-msbuild3-final" />
</ItemGroup>
@garywoodfine

This comment has been minimized.

Show comment
Hide comment
@garywoodfine

garywoodfine Feb 28, 2017

@dasMulli Thanks
I had
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.1.0-preview4-final" />`

But now when I try
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.0-msbuild3-final" />

I just get "ef is not recognized as an internal or external command"

I have tried with both packages together and I am back to the original error

--Edit
So I now finally have it working the steps I went through are, just in case anyone else had this issue.

I removed the reference to
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.1.0-preview4-final" />`

Then did a dotnet restore on the terminal

then added the reference to
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.0-msbuild3-final" />

then did a dotnet restore on the terminal

then tried dotnet ef and everything started working
Thanks @dasMulli

garywoodfine commented Feb 28, 2017

@dasMulli Thanks
I had
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.1.0-preview4-final" />`

But now when I try
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.0-msbuild3-final" />

I just get "ef is not recognized as an internal or external command"

I have tried with both packages together and I am back to the original error

--Edit
So I now finally have it working the steps I went through are, just in case anyone else had this issue.

I removed the reference to
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.1.0-preview4-final" />`

Then did a dotnet restore on the terminal

then added the reference to
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.0-msbuild3-final" />

then did a dotnet restore on the terminal

then tried dotnet ef and everything started working
Thanks @dasMulli

@asbjornu

This comment has been minimized.

Show comment
Hide comment
@asbjornu

asbjornu Feb 28, 2017

@garywoodfine, @dasMulli: Can you please move this support discussion out into a relevant issue? 😄

@garywoodfine, @dasMulli: Can you please move this support discussion out into a relevant issue? 😄

@udev

This comment has been minimized.

Show comment
Hide comment
@udev

udev Mar 7, 2017

I'm late to the game but wanted to chime in here:

Getting rid of project.json in favor of an MSBuild based alternative will pretty much kill my present company's ambitions of supporting .NET at scale. I've recently inherited some .NET based work that needs to be brought current and was pretty excited to see what has changed in the world of .NET over the past decade (I haven't actively used .NET since 2010 and stopped using Windows altogether in 2013). With a move back to Visual Studio, even if there is support for Mac, it's looking unlikely that there will be interest in supporting Microsoft platforms moving forward.

udev commented Mar 7, 2017

I'm late to the game but wanted to chime in here:

Getting rid of project.json in favor of an MSBuild based alternative will pretty much kill my present company's ambitions of supporting .NET at scale. I've recently inherited some .NET based work that needs to be brought current and was pretty excited to see what has changed in the world of .NET over the past decade (I haven't actively used .NET since 2010 and stopped using Windows altogether in 2013). With a move back to Visual Studio, even if there is support for Mac, it's looking unlikely that there will be interest in supporting Microsoft platforms moving forward.

@gulshan

This comment has been minimized.

Show comment
Hide comment
@gulshan

gulshan Mar 7, 2017

@udev MSBuild is now cross-platform as it is built with .net core. Moving back to MSBuild doesn't mean going back Visual Studio. The command line tools and VSCode with Omnisharp can be used to develop .net everywhere.

gulshan commented Mar 7, 2017

@udev MSBuild is now cross-platform as it is built with .net core. Moving back to MSBuild doesn't mean going back Visual Studio. The command line tools and VSCode with Omnisharp can be used to develop .net everywhere.

@colin-young

This comment has been minimized.

Show comment
Hide comment
@colin-young

colin-young Mar 8, 2017

I'm doing work on a Mac with VS Code and Visual Studio Mac, and the command line, and while I'm not a huge fan of the old MSBuild csproj, even I have to admit the new experience is kind of awesome.

I'm doing work on a Mac with VS Code and Visual Studio Mac, and the command line, and while I'm not a huge fan of the old MSBuild csproj, even I have to admit the new experience is kind of awesome.

@gulshan

This comment has been minimized.

Show comment
Hide comment
@gulshan

gulshan Mar 8, 2017

I think Type Providers in C# will help a lot to fulfill the goal of this proposal.

gulshan commented Mar 8, 2017

I think Type Providers in C# will help a lot to fulfill the goal of this proposal.

@svick svick referenced this issue in Microsoft/dotnet May 24, 2017

Closed

Project.json no longer works #411

@StingyJack

This comment has been minimized.

Show comment
Hide comment
@StingyJack

StingyJack Dec 28, 2017

In 20 years I have yet to work with a developer who cares one bit about proj files being in xml or some other format.

Only a handful even understand what the file actually does or how to alter it to make life easier or fix problems. This seems like work for work's sake.

In 20 years I have yet to work with a developer who cares one bit about proj files being in xml or some other format.

Only a handful even understand what the file actually does or how to alter it to make life easier or fix problems. This seems like work for work's sake.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment