search

dotnet / msbuild

The Microsoft Build Engine (MSBuild) is the build platform for .NET and Visual Studio.
https://docs.microsoft.com/visualstudio/msbuild/msbuild
MIT License
5.21k stars 1.35k forks source link

Support yaml/json #16

Closed hmemcpy closed 8 years ago

hmemcpy commented 9 years ago

Opening this issue to get the discussion going -- xml is very verbose. Many project nowadays opt for configuring using YAML or json. It would be great to have support for those in msbuild.

ChaseFlorell commented 9 years ago

I don't believe yaml is in fact markup, but I'm all for json... Much clearer.

arbing commented 9 years ago

json +1

nilemarbarcelos commented 9 years ago

json +1 here

WellMafra commented 9 years ago

json +1²

arthrp commented 9 years ago

JSON would be totally in spirit of the "new" .NET, +1

RichiCoder1 commented 9 years ago

I'd be curious how a json formatted MSBuild project file would play with AspNet vNext's project.json.

shahid-pk commented 9 years ago

json support will be great of course after getting msbuild xplat

hmemcpy commented 9 years ago

One important bit about json config is the (lack of) comments,which are useful in a build configuration. How would json support that?

arthrp commented 9 years ago

@hmemcpy the fact that official JSON standard doesn't support comments doesn't mean a thing. JS comments can be easily handled by a JSON parser.It doesn't need to be "Crockford's valid JSON", you know.

akoeplinger commented 9 years ago

I think it would be helpful if someone converted an existing MSBuild solution (e.g. this repo) to json so we can see how it looks like :)

AndyGerlicher commented 9 years ago

Without being for or against this suggestion, the main thing we would need to keep in mind is alignment with Visual Studio and the project files. It's something we will definitely bring up for Visual Studio vNext, but I'm not sure that we would take a change right now for the current MSBuild incarnation as it would likely be fairly substantial.

leppie commented 9 years ago

:-1:

Unless someone plans to write a JSON 'schema validator' this will not happen. XML has all that built in.

A better choice would be some JSON to MsBuild XML preprocessor task. Well anyone can do that, it does not have to be built into MsBuild.

RichiCoder1 commented 9 years ago

@leppie JSON Schema and Schema validation is a thing. See ASP.NET's project.json: https://github.com/aspnet/Home/wiki/Project.json-file

skizzerz commented 9 years ago

YAML is a superset of JSON, so I'd rather see support for YAML (which would thus automatically include JSON support unless YAML-specific features like multiple documents in a single file are required). YAML is also a lot easier to hand-modify in case that matters for people (comes up for me very occasionally where I need to manually edit a .csproj because I accidentally did something derpy in VS that I couldn't fully revert).

ChaseFlorell commented 9 years ago

@darrelmiller, I know what it means, but it's not really 'markup'. Just my opinion, but I'm not a fan. Invisible characters have no place as deliminators. Json support on the other hand aligns nicely with the vnext direction.

Also, extra data inside json wouldn't affect its purpose, so comments can easily just be extra data. When parsed, comments show up as properties.

{"_comment":"I'm a comment. "}
darrelmiller commented 9 years ago

@ChaseFlorell I deleted my comment because I was wrong about what YAML stands for :open_mouth: Anyway, I realize the momentum is going to be behind JSON, but having worked with both, I personally find YAML so much more pleasant.

Mike-E-angelo commented 9 years ago

I hate to be the lone ranger here. :) (actually, I think @ChaseFlorell can back me up here if he is who I think he is. :smile:). But I would LOVE to see MSBuild support Xaml. Xaml already has built-in designer and tooling support in VisualStudio, and has rich support for intellisense through add-ons such as ReSharper. Not to mention, it is used everywhere in MSFT ecosystem these days (except ASP.NET, but I personally hope to see that change that as well. :smile:). Xamarin is also blowing up with a bunch of Xaml adoption as well. It's pretty ubiquitous and should definitely be considered here.

Xaml is thought of as presentation markup, but it is an object definition language that can be used anywhere. Again, it comes with built-in rich tooling support for free. As a quick example, here are some POCOs that I've designed: .

And here is a a corresponding simple Xaml definition: ,

When I select the root element with my mouse, this is what I see in the Properties Pane: .

All for free, right now in Visual Studio. If you have ever worked with Blend, then you know those controls are Blend designer controls and comes with all the designer/tooling support with them (for instance, that enum is a dropdown with all of its supported values). We can even create our own custom editors for properties if we so desired (and once the community grows, so will this desire, I'm sure :)).

Finally, by using Xaml, you get to take advantage of the one unique component that nothing else in the entire world uses: MARKUP EXTENSIONS! This is what makes Xaml so incredibly awesome and fun to work with.

I know some people find XML/Xaml as verbose, but I (and others) find it expressive and powerful. I would also like to say that Xaml is NOT Xml. It is its own animal altogether and should be considered separately in its own right, IMO.

I would LOVEEEE to have this functionality with MSBuild!!!

Mike-E-angelo commented 9 years ago

Some additional considerations as well:

XML was intended and designed to be language-agnostic. I know that JSON is the new, shiny kid on on the block, but it violates this principle this just by its very name. Also, the magic schema it is using is (in my view) suspect, as it introduces dynamic (unstructured/unknown/loose) properties that may or may not be consumed/understood/known by its consumers, possibly causing inadvertent side effects. Finally, and this is nit-picky, but it also introduces unnecessary overhead to the file (in that it introduces data into the file that is intended to only be known by designers, that now potentially goes over the wire), which flies in the face of its "lightweight/optimized" value proposition.

Furthermore, when using the current JSON schema mechanism, it references another artifact that lives on the system somewhere. So now, from a tooling (and management) perspective, we have to account for 2 artifacts instead of one. This is exactly how the .NET configuration mechanism worked and it was a burden to work with (even more so as it required you to create configuration mapping items altogether to map between the POCO and configuration elements, but I digress).

Using the class definition as the schema (as Xaml does) is the way to go, as you only end up dealing with one artifact and all tooling is derived from there (the class definition). You are also ensured of proper, consistent, and congruent property casing which was also another annoying side effect of .NET xml configuration (and JSON Schemas) [e.g. "PropertyName" is defined in the class file while "propertyName" is defined in the Xml/JSON file].

Once JSON uses class definitions as schemas, then I feel it can start to be considered as a legitimate object definition "markup" (please kindly recall that JSON is actually code) language. But then, at that point, it's being exactly like Xaml... so why not go with the option that has the more history/maturity and (most importantly) tooling support (this is what makes us efficient, after all!).

... and then there's that whole language-agnostic thing... oh, and markup extensions. :)

I'm not trying to start a JSON vs Xaml fight (ok, maybe a little :innocent:), but I am trying to make sure all points of view are considered here before we all go chasing the new shiny toy. Some of us have been around a while here and there are reasons why we do the things we do... so it's good to discuss these things and get them out and have all points considered. :)

brianlagunas commented 9 years ago

I actually like the idea of XAML over JSON. If I had to write MSBuild configurations in JSON, I would probably want to jump out a window.

eatdrinksleepcode commented 9 years ago

@Michael-DST

XML was intended and designed to be language-agnostic.

From [json.org](): "JSON is a text format that is completely language independent." (In fact they are both their own languages, hence the L in XML; but they are markup languages rather than general purpose languages.)

Also, the magic schema [JSON] is using...

Not sure what "magic" you are talking about. Just like XML, JSON can be schemaless, or it can be tied to a schema.

it also introduces unnecessary overhead to the file (in that it introduces data into the file that is intended to only be known by designers...

Not sure what you are talking about here; what "designers"?

Furthermore, when using the current JSON schema mechanism, it references another artifact that lives on the system somewhere. So now, from a tooling (and management) perspective, we have to account for 2 artifacts instead of one... Using the class definition as the schema (as Xaml does) is the way to go, as you only end up dealing with one artifact and all tooling is derived from there (the class definition).

In both cases, there is a schema definition that lives separately from the markup; in XML/JSON its a schema file, in XAML its a class, but there are no fewer artifacts to deal with by using XAML. (Not to mention, doesn't using a class for the schema definition destroy the "language agnostic" characteristic you were advocating for?)

...please kindly recall that JSON is actually code...

No, it's not. It may have started out that way, but [json.org](language definition for JSON) clearly specifies that only objects and scalar values are valid; arbitrary expressions are not allowed.

...why not go with the option that has the more history/maturity...

Xaml may have more history, but JSON is and will always be more widely supported in the software industry (and the same is true for XML). I don't know that I want a new developer to have to learn XAML AND MSBuild just to understand how our build works (see my following comment on build DSLs).

...and (most importantly) tooling support...

Tooling support - especially visual tooling, which seems to be what you are talking about - is definitely NOT the most important thing in a build tool. I value visual designers when they are appropriate, but a point-and-click designer for a build tool would just slow me down compared to a fast code editor with Intellisense.

The thing is, I am not necessarily opposed to XAML over XML for MSBuild. I used WPF heavily for several years, and really appreciated the power and expressiveness of XAML. But it is verbose, and it is complex, and there is a steep learning curve compared to most markup languages. XAML would have to provide significant benefits for the build system to be worth considering over XML, especially given that MSBuild needs to be approachable by any developer on any .NET project. In my opinion, you haven't provided any significant evidence of such benefits.

eatdrinksleepcode commented 9 years ago

I think it is worth considering that markup is not the language of choice for modern build systems. MSBuild was created at a time when Ant, NAnt, and Maven were some of the most popular build systems. But today, Gradle, Rake, and Grunt are becoming the tools of choice, and for good reason. Build systems based on code rather than markup use DSLs to make doing the simple things easy, while making the hard things possible, without jumping completely outside of the build system to do them. My own hard experience with both MSBuild and Maven has shown me the pain that results from pretending that the build isn't a software system of its own. We should treat it as such by using the best tools we have available for building software.

My opinion is that the best option for a new language for MSBuild would be the new C# scripting abilities being built into Roslyn.

RichiCoder1 commented 9 years ago

I would not be against MSBuild allowing C# like scripting for builds, especially along the lines of something like Bau or Cake.

Mike-E-angelo commented 9 years ago

Cool. Thank you for the discussion @eatdrinksleepcode. :) I knew I was gonna rile someone up after I posted all that... I almost deleted it haha.

To start with, when I say language-agnostic, I mean it is agnostic from any other language from itself. JSON's (original) intent is to be consumed by a JavaScript or JavaScript-aware client for serialization/conversion into a JavaScript application. I realize it can be used in any application, but I am just looking at it from the perspective from other non-JS languages. To me, it's about the equivalent as seeing a VBON (VB) or CSON (C#). Sure, those would make sense in their two respective paradigms, but outside, of it... well, that's where we run into this area. (To be sure, I am not saying those exist... but just saying that's what it is like.)

Not sure what "magic" you are talking about. / Not sure what you are talking about here; what "designers"?

More succinctly, the consumers of the file format that provide design-support. In this case, MSBuild (or Visual Studio). When I say "magic" I am referring to the "$schema" attribute. If I understand correctly, this points to another artifact altogether to that is the schema to describe the data, correct? That means that 1) someone somewhere has to create that artifact at some point and 2) know where it is and reference it in their file. The schema in Xaml is inferred from the class itself, so there's no other external artifact than the current file that you need to worry about. That makes it easier to create/manage/maintain/etc.

Not to mention, doesn't using a class for the schema definition destroy the "language agnostic" characteristic you were advocating for?

Xaml is also still language agnostic in this case, as the class it is pointing to could have been compiled as C#, or VB, or even F#. That is what is (one of the many things) awesome about it, IMO. :)

Tooling support - especially visual tooling, which seems to be what you are talking about - is definitely NOT the most important thing in a build tool.

Well, I am not so sure about this. There is so much to be done in this area, innovation-wise. But at this point I am mostly talking about intellisense. And the intellisense with Xaml (especially with ReSharper) is so much better than what is offered with Xml and JSON (at the moment, I'm sure it will get better). The fact that so much has been done around its format in Visual Studio for presentation tooling (in WPF, etc) makes it all the better (again, I think there is so much innovation left to be done in this area to get to what I am talking about).

I don't know that I want a new developer to have to learn XAML AND MSBuild just to understand how our build works (see my following comment on build DSLs).

I would like to make sure here that "learning Xaml" isn't being distorted by your perception of how complex WPF is. They are totally separate. Xaml is just XML, and I think as far as its object definition qualities go, developers can jump right in, as they can leverage the ubiquitousness (that's a word haha) of XML.

With all of this said, I am 100% with you about Roslyn and its new tooling. What I personally would like to see done is a new "Data AST (Abstract Syntax Tree) Format" that is a new file format (call it .dast for the sake of this discussion). When this file is opened in Visual Studio, it displays it to the developer in the format that the developer prefers it (JSON, XML, Xaml, Yaml, etc etc).

That way, the data gets saved (in a particular format, which may or may not be proprietary), and then whenever it is opened, it is presented in a preferred format, and is designed so accordingly.

Not sure how viable that is short-term and what that means for MSBuild, however. :) The thing you are fighting with me here on is that I (and you, it sounds) know what the Xaml development/designer experience is like, and it's quite nice (especially with ReSharper). JSON development/designer support is going to be a while before it gets up to Xaml-status (plus it suffers from multiple-artifact syndrome which I still think needs to be resolved elegantly). I also feel that Xaml is a natural successor to the existing XML file format, especially since we are talking about a C#/VB/.NET where all of these projects have been built by MSBuild for over a decade (and again is benefiting from the same environment that currently already offers so much tooling support).

Admittedly, I am not aware of the other technologies you (or @RichiCoder1) reference, so I guess I have some research to do. I just cringe whenever I see code that can be defined declaratively, and that's really what we're after here.

I hope this clarifies my position. Thank you again for your input.

Mike-E-angelo commented 9 years ago

Just thinking about this some more and to echo what @RichiCoder1 said... if you cleanly expose the API as C# (or even .NET) objects, then we Xamlites (I just made that up) can build Xaml around that. It doesn't really need to be anything special, especially with what Xamarin is cooking up these days. There's no reason not to support both JSON and Xaml, I guess is what I am trying to say. Heck, if you make JSON the official supported file type (not saying that you should :sweat_smile:, but if you do), I could see myself making a fork that enables the corresponding Xaml equivalent functionality, for starters.

(FWIW, this is what I intend on doing with ASP.NET 5's new configuration API, which is designed to support different configuration providers/formats.)

As long as the MSBuild team is aware of the want/need for multiple declarative file format support and provide the necessary design/hooks to easily consume their API in whatever format we prefer, that's what's really important here. :+1:

JohnTasler commented 9 years ago

I like the XAML idea. I do think that the class in this case is an artifact. However, it is an artifact that also represents the internal .NET object. The System.Xaml.XamlReader class has a mature implementation that reads that in for us, with strong type checking. Because of this, the MsBuild system could pre-compile the build definition into BAML (the binary representation of XAML). This could make the build system much faster, since BAML translates to an in-memory object more efficiently than runtime string parsing and schema checking.

sam-source commented 9 years ago

@eatdrinksleepcode is on the right track.+1 to C# scripting

RichiCoder1 commented 9 years ago

@Michael-DST An pluggable, language/format-agnostic API/interface for MSBuild would probably tops really, as this thread shows theres many different formats that people'd like to define builds in. That being said, that'd be no small task, and still probably require one or more built in build configuration parsers.

Mike-E-angelo commented 9 years ago

Yes, and now thinking about it, there really isn't a need for a proprietary file format (.dast) after all (although you could still create one from a branding/optimized/value perspective). It really comes down to the data (saved/stored format) and the view (presentation format). Roslyn offers pretty exciting improvements in this regard and can handle everything in between. Once Visual Studio loads the file, it can run its own conversion process (via Roslyn) between the two formats.

It will be an awesome day in technology when one can open up a .json file, have it render as .xaml via Roslyn conversion, edit/design as .xaml, and then when saved, it saves it as back as .json. And vice versa. :)

(Although, JSON does not support markup extensions -- ahem :innocent: -- so some additional thought would be required around that and other capability discrepancies.)

As an aside, I would be remiss if I didn't mention my vote on Visual Studio for .ast code views. I am beginning to feel that the .dast we are talking about here is an extension component of this concept. You are right in saying that this is no small task, and I hope to inspire some light bulbs out there by mentioning it to get the ball rolling. I feel this thread really underscores that we are "pawing at an elephant in a dark room" here that and this "elephant" is bound to be a legitimate GitHub project at some point -- either officially by MSFT or by someone with extra time on their hands (which is obviously not me at the moment :smile:). If someone started it, I for one would totally support it. This is a well-overdue feature for software development!

mikehaas763 commented 9 years ago

If it's simply a serialization format such as JSON or YAML, please make the serializer itself that's being used swappable through configuration, etc. Think about that for a second :) Configurable configuration ha.

I also like the idea of being able to use C# directly, however I could see that making things a bit more difficult as the abstraction would have to be higher up than just the serializer.

eatdrinksleepcode commented 9 years ago

@arthur-peka, another markup langauge would undoubtedly be easier, as the current model is built with a markup language in mind. But just because it is easier does not mean it is the right direction for the future :)

Implementing scripting language support may ultimately deserve its own proposal, but given that even implementing another markup language is considered "distant future", I don't think it is worth tracking scripting language support separately right now. I mostly just want people who are interested in and thinking about implementing something other than XML for MSBuild to have scripting in mind.

ghost commented 9 years ago

@leppie, you can write JSON schema today, see https://github.com/json-schema/json-schema. @madskristensen has written handful of JSON schemas for various implementations: .jshintrc, .jscsrc, tslit.json, package.json (node.js) etc. which works with both VS2013 and VS2015. Also check this out https://github.com/madskristensen/JSON-Intellisense/blob/master/README.md,

seanmiddleditch commented 9 years ago

No JSON, please.

JSON is a data-interchange format. It was never "designed" to be used as a source format.

JSON is hard to merge. JSON has odd syntactical requirements that insert noise in places that handily confuse merge tools. Remember, project files are basically part of the project's source, and so need to be as friendly to all tools as possible, including merge tools.

ex: The need in JSON to put a trailing comma after every item in an array/object except the last one means that merging two edits that both add items to the end of a list is always a conflict, unnecessarily. Let's not then get started on the problems of users adding single-line arrays/objects and conflicts there-in (the same thing can happen with XML, but such single-line structures aren't nearly as idiomatic/common in XML as they are in JSON).

This is why projects like HJSON exist. If you're arguing for a cleaner and more human-friendly file format, the mere existence of projects like HJSON should rather clearly indicate that JSON itself is a bad choice (in many ways, it's a step backwards from XML). HJSON also avoids the indentation madness of YAML, btw. And HJSON is just a dialect of JSON, so it's conceptually compatible with all the schema tools that people have tried to bolt on to JSON a posteriori ... I'm saying you should look into HJSON. :)

Also, XML is a perfectly fine language if used well. Unfortunately, msbuild's current schema is poorly designed and endemic to Microsoft's culture from the late 90's and early 00's. A rewrite and massive cleanup and redesign of the schema would do wonders without actually needing to support a new data format. Also, that macro language in msbuild... switching to a new data format won't fix that. Point being, if your complaint is that msbuild's specification is complicated and ugly, blame of XML is massively misplaced.

Mike-E-angelo commented 9 years ago

Wow @seanmiddleditch that HJSON is indeed very telling, exactly as you put it. Great find. Does this mean we can make HXaml and all will be right in the world? :)

wgssmiddleditch commented 9 years ago

@Michael-DST : sure. I don't know of any standard (I'm 93% sure there is one if you look hard enough), but there's almost more home-grown "HXML"-like formats than you can shake a stick at. Jade is the best standard I can think of here, though it's HTML-focused and relies on whitespace/indentation for structure.

A human-readable dialect is still very much second fiddle to the actual schema itself, though. The most pleasant and concise syntax in the world is worthless if the structure itself is poor.

Consider Google's gyp, which is a JSON-based meta-project system (akin to CMake). I still think that Gyp has the hardest to read project files of all the tools of its ilk. Consider just the tail end of the sample .gyp file from that link:

         ],
        }]
      ],
    },
  ],
}

And before someone else mentions it: yes, there are JSON-aware merge algorithms, but source data formats like Microsoft's project files need to be compatible with all the merge tools in common use, most of which can barely manage simple text adequately much less formats that require special merge algorithms.

Mike-E-angelo commented 9 years ago

For anyone who is interested, I have created a UserVoice vote on Visual Studio that mentions this great discussion and defines the problems with the current build system that need to be addressed: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/9347001-improve-reboot-visual-studio-project-system

Additionally, I have proposed a new idea/vote on UserVoice for an idea that would also address this problem from a developer perspective: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/10020525-enable-roslyn-powered-data-asts-and-data-views

In this vote, there is a blog post that explains the idea in more detail. Thank you for any feedback and/or support. :)

Mike-E-angelo commented 8 years ago

This is a little late here, but I just got done making a simple app that demonstrates what I discussed above with Xaml-based application development. Please see this file: https://github.com/DragonSpark/VoteReporter/blob/master/DevelopersWin.VoteReporter.Application/Program.xaml

And (probably more importantly?) this file: https://github.com/DragonSpark/VoteReporter/blob/master/DevelopersWin.VoteReporter.Application/Program.xaml.cs

Here is a good example of a Xaml-driven application (or at least my definition of it) -- or more succinctly a Xaml-driven Console Application (you can see in the code-behind above how the Main method is defined). In this case, all of the "steps" of the application startup are encapsulated in System.Windows.Input.ICommand's and they are called in succession to execute very discrete and encapsulated commands. These commands are then defined in the Program.xaml file as Xaml elements that can be used to define all of the inputs and (what others might consider) configuration for the application.

The power again is the markup extensions. There are some really cool ones here that are being used, such as creating a DirectoryInfo object that is used by subsequent components via IoC: https://github.com/DragonSpark/VoteReporter/blob/master/DevelopersWin.VoteReporter.Application/Program.xaml#L22

Additionally, this line tells the application to pull all registered IInstaller's found within the current AppDomain and add them to the collection found within the InitializeDatabaseCommand: https://github.com/DragonSpark/VoteReporter/blob/master/DevelopersWin.VoteReporter.Application/Program.xaml#L44

Very powerful stuff (I say, as I wrote it, LOL). In any case, this is how I see/envision MSBuild vNext being implemented, and the new build projects looking very much like this. It doesn't take much of a jump to see that ICommands could be build Tasks (or probably both? that is, Tasks implement ICommand?) and they can (should) be defined in very much the same way. Anyways, I just had to share. Thanks again for any consideration/discussion.

Gum-Joe commented 8 years ago

Hi, Being a user of msbuild myself, I think it is good that you are deciding to possibly use json/yaml. I went online and converted a msbuild c++ project which looked like this:

<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup Label="ProjectConfigurations">
    <ProjectConfiguration Include="Debug|x64">
      <Configuration>Debug</Configuration>
      <Platform>x64</Platform>
    </ProjectConfiguration>
    <ProjectConfiguration Include="Release|x64">
      <Configuration>Release</Configuration>
      <Platform>x64</Platform>
    </ProjectConfiguration>
  </ItemGroup>
  <PropertyGroup Label="Globals">
    <ProjectGuid>{74CF4537-8047-617D-4D23-0353B4FC702F}</ProjectGuid>
    <Keyword>Win32Proj</Keyword>
    <RootNamespace>pem</RootNamespace>
    <IgnoreWarnCompileDuplicatedFilename>true</IgnoreWarnCompileDuplicatedFilename>
    <PreferredToolArchitecture>x64</PreferredToolArchitecture>
  </PropertyGroup>
  <Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props"/>
  <PropertyGroup Label="Configuration">
    <ConfigurationType>DynamicLibrary</ConfigurationType>
  </PropertyGroup>
  <PropertyGroup Label="Locals">
    <PlatformToolset>v140</PlatformToolset>
  </PropertyGroup>
  <Import Project="$(VCTargetsPath)\Microsoft.Cpp.props"/>
  <Import Project="$(VCTargetsPath)\BuildCustomizations\masm.props"/>
  <ImportGroup Label="ExtensionSettings"/>
  <ImportGroup Label="PropertySheets">
    <Import Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props"/>
  </ImportGroup>
  <PropertyGroup Label="UserMacros"/>
  <PropertyGroup>
    <ExecutablePath>$(ExecutablePath);$(MSBuildProjectDirectory)\..\bin\;$(MSBuildProjectDirectory)\..\bin\</ExecutablePath>
    <IgnoreImportLibrary>true</IgnoreImportLibrary>
    <IntDir>$(Configuration)\obj\$(ProjectName)\</IntDir>
    <LinkIncremental Condition="'$(Configuration)|$(Platform)'=='Release|x64'">false</LinkIncremental>
    <LinkIncremental Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">true</LinkIncremental>
    <OutDir>$(SolutionDir)$(Configuration)\</OutDir>
    <TargetExt Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">.node</TargetExt>
    <TargetExt Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">.node</TargetExt>
    <TargetExt Condition="'$(Configuration)|$(Platform)'=='Release|x64'">.node</TargetExt>
    <TargetExt Condition="'$(Configuration)|$(Platform)'=='Release|x64'">.node</TargetExt>
    <TargetName>$(ProjectName)</TargetName>
    <TargetPath>$(OutDir)\$(ProjectName).node</TargetPath>
  </PropertyGroup>
  <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
    <ClCompile>
      <AdditionalIncludeDirectories>C:\Users\Kishan Sambhi\.node-gyp\4.2.2\include\node;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\src;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\deps\uv\include;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\deps\v8\include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
      <BasicRuntimeChecks>EnableFastChecks</BasicRuntimeChecks>
      <BufferSecurityCheck>true</BufferSecurityCheck>
      <CompileAsWinRT>false</CompileAsWinRT>
      <DebugInformationFormat>ProgramDatabase</DebugInformationFormat>
      <DisableSpecificWarnings>4351;4355;4800;4251;%(DisableSpecificWarnings)</DisableSpecificWarnings>
      <ExceptionHandling>false</ExceptionHandling>
      <MinimalRebuild>false</MinimalRebuild>
      <OmitFramePointers>false</OmitFramePointers>
      <Optimization>Disabled</Optimization>
      <PrecompiledHeader>NotUsing</PrecompiledHeader>
      <PreprocessorDefinitions>NODE_GYP_MODULE_NAME=pem;WIN32;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_HAS_EXCEPTIONS=0;BUILDING_V8_SHARED=1;BUILDING_UV_SHARED=1;BUILDING_NODE_EXTENSION;DEBUG;_DEBUG;%(PreprocessorDefinitions)</PreprocessorDefinitions>
      <RuntimeLibrary>MultiThreadedDebug</RuntimeLibrary>
      <StringPooling>true</StringPooling>
      <SuppressStartupBanner>true</SuppressStartupBanner>
      <TreatWarningAsError>false</TreatWarningAsError>
      <WarningLevel>Level3</WarningLevel>
    </ClCompile>
    <Link>
      <AdditionalDependencies>kernel32.lib;user32.lib;gdi32.lib;winspool.lib;comdlg32.lib;advapi32.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;odbc32.lib;DelayImp.lib;&quot;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\$(Configuration)\node.lib&quot;</AdditionalDependencies>
      <AdditionalOptions>/ignore:4199 %(AdditionalOptions)</AdditionalOptions>
      <AllowIsolation>true</AllowIsolation>
      <DataExecutionPrevention>true</DataExecutionPrevention>
      <DelayLoadDLLs>iojs.exe;node.exe;%(DelayLoadDLLs)</DelayLoadDLLs>
      <GenerateDebugInformation>true</GenerateDebugInformation>
      <GenerateMapFile>true</GenerateMapFile>
      <MapExports>true</MapExports>
      <OutputFile>$(OutDir)$(ProjectName).node</OutputFile>
      <RandomizedBaseAddress>true</RandomizedBaseAddress>
      <SuppressStartupBanner>true</SuppressStartupBanner>
      <TargetExt>.node</TargetExt>
      <TargetMachine>MachineX64</TargetMachine>
    </Link>
    <ResourceCompile>
      <AdditionalIncludeDirectories>C:\Users\Kishan Sambhi\.node-gyp\4.2.2\include\node;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\src;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\deps\uv\include;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\deps\v8\include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
      <PreprocessorDefinitions>NODE_GYP_MODULE_NAME=pem;WIN32;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_HAS_EXCEPTIONS=0;BUILDING_V8_SHARED=1;BUILDING_UV_SHARED=1;BUILDING_NODE_EXTENSION;DEBUG;_DEBUG;%(PreprocessorDefinitions);%(PreprocessorDefinitions)</PreprocessorDefinitions>
    </ResourceCompile>
  </ItemDefinitionGroup>
  <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
    <ClCompile>
      <AdditionalIncludeDirectories>C:\Users\Kishan Sambhi\.node-gyp\4.2.2\include\node;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\src;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\deps\uv\include;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\deps\v8\include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
      <AdditionalOptions>/MP %(AdditionalOptions)</AdditionalOptions>
      <BufferSecurityCheck>true</BufferSecurityCheck>
      <CompileAsWinRT>false</CompileAsWinRT>
      <DebugInformationFormat>ProgramDatabase</DebugInformationFormat>
      <DisableSpecificWarnings>4351;4355;4800;4251;%(DisableSpecificWarnings)</DisableSpecificWarnings>
      <ExceptionHandling>false</ExceptionHandling>
      <FavorSizeOrSpeed>Speed</FavorSizeOrSpeed>
      <FunctionLevelLinking>true</FunctionLevelLinking>
      <InlineFunctionExpansion>AnySuitable</InlineFunctionExpansion>
      <IntrinsicFunctions>true</IntrinsicFunctions>
      <OmitFramePointers>true</OmitFramePointers>
      <Optimization>Full</Optimization>
      <PrecompiledHeader>NotUsing</PrecompiledHeader>
      <PreprocessorDefinitions>NODE_GYP_MODULE_NAME=pem;WIN32;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_HAS_EXCEPTIONS=0;BUILDING_V8_SHARED=1;BUILDING_UV_SHARED=1;BUILDING_NODE_EXTENSION;%(PreprocessorDefinitions)</PreprocessorDefinitions>
      <RuntimeLibrary>MultiThreaded</RuntimeLibrary>
      <RuntimeTypeInfo>false</RuntimeTypeInfo>
      <StringPooling>true</StringPooling>
      <SuppressStartupBanner>true</SuppressStartupBanner>
      <TreatWarningAsError>false</TreatWarningAsError>
      <WarningLevel>Level3</WarningLevel>
      <WholeProgramOptimization>true</WholeProgramOptimization>
    </ClCompile>
    <Lib>
      <AdditionalOptions>/LTCG %(AdditionalOptions)</AdditionalOptions>
    </Lib>
    <Link>
      <AdditionalDependencies>kernel32.lib;user32.lib;gdi32.lib;winspool.lib;comdlg32.lib;advapi32.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;odbc32.lib;DelayImp.lib;&quot;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\$(Configuration)\node.lib&quot;</AdditionalDependencies>
      <AdditionalOptions>/ignore:4199 %(AdditionalOptions)</AdditionalOptions>
      <AllowIsolation>true</AllowIsolation>
      <DataExecutionPrevention>true</DataExecutionPrevention>
      <DelayLoadDLLs>iojs.exe;node.exe;%(DelayLoadDLLs)</DelayLoadDLLs>
      <EnableCOMDATFolding>true</EnableCOMDATFolding>
      <GenerateDebugInformation>true</GenerateDebugInformation>
      <GenerateMapFile>true</GenerateMapFile>
      <LinkTimeCodeGeneration>UseLinkTimeCodeGeneration</LinkTimeCodeGeneration>
      <MapExports>true</MapExports>
      <OptimizeReferences>true</OptimizeReferences>
      <OutputFile>$(OutDir)$(ProjectName).node</OutputFile>
      <RandomizedBaseAddress>true</RandomizedBaseAddress>
      <SuppressStartupBanner>true</SuppressStartupBanner>
      <TargetExt>.node</TargetExt>
      <TargetMachine>MachineX64</TargetMachine>
    </Link>
    <ResourceCompile>
      <AdditionalIncludeDirectories>C:\Users\Kishan Sambhi\.node-gyp\4.2.2\include\node;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\src;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\deps\uv\include;C:\Users\Kishan Sambhi\.node-gyp\4.2.2\deps\v8\include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
      <PreprocessorDefinitions>NODE_GYP_MODULE_NAME=pem;WIN32;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_HAS_EXCEPTIONS=0;BUILDING_V8_SHARED=1;BUILDING_UV_SHARED=1;BUILDING_NODE_EXTENSION;%(PreprocessorDefinitions);%(PreprocessorDefinitions)</PreprocessorDefinitions>
    </ResourceCompile>
  </ItemDefinitionGroup>
  <ItemGroup>
    <None Include="..\binding.gyp"/>
  </ItemGroup>
  <ItemGroup>
    <ClCompile Include="..\src\pem.cc"/>
    <ClCompile Include="C:\Users\Kishan Sambhi\AppData\Roaming\npm\node_modules\node-gyp\src\win_delay_load_hook.c"/>
  </ItemGroup>
  <Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets"/>
  <Import Project="$(VCTargetsPath)\BuildCustomizations\masm.targets"/>
  <ImportGroup Label="ExtensionTargets"/>
</Project>

to json and yaml JSON:

{
  "Project": {
    "-xmlns": "http://schemas.microsoft.com/developer/msbuild/2003",
    "-DefaultTargets": "Build",
    "-ToolsVersion": "14.0",
    "ItemGroup": [
      {
        "-Label": "ProjectConfigurations",
        "ProjectConfiguration": [
          {
            "-Include": "Debug|x64",
            "Configuration": "Debug",
            "Platform": "x64"
          },
          {
            "-Include": "Release|x64",
            "Configuration": "Release",
            "Platform": "x64"
          }
        ]
      },
      {
        "None": { "-Include": "..\\binding.gyp" }
      },
      {
        "ClCompile": [
          { "-Include": "..\\src\\pem.cc" },
          { "-Include": "C:\\Users\\Kishan Sambhi\\AppData\\Roaming\\npm\\node_modules\\node-gyp\\src\\win_delay_load_hook.c" }
        ]
      }
    ],
    "PropertyGroup": [
      {
        "-Label": "Globals",
        "ProjectGuid": "{74CF4537-8047-617D-4D23-0353B4FC702F}",
        "Keyword": "Win32Proj",
        "RootNamespace": "pem",
        "IgnoreWarnCompileDuplicatedFilename": "true",
        "PreferredToolArchitecture": "x64"
      },
      {
        "-Label": "Configuration",
        "ConfigurationType": "DynamicLibrary"
      },
      {
        "-Label": "Locals",
        "PlatformToolset": "v140"
      },
      { "-Label": "UserMacros" },
      {
        "ExecutablePath": "$(ExecutablePath);$(MSBuildProjectDirectory)\\..\\bin\\;$(MSBuildProjectDirectory)\\..\\bin\\",
        "IgnoreImportLibrary": "true",
        "IntDir": "$(Configuration)\\obj\\$(ProjectName)\\",
        "LinkIncremental": [
          {
            "-Condition": "'$(Configuration)|$(Platform)'=='Release|x64'",
            "#text": "false"
          },
          {
            "-Condition": "'$(Configuration)|$(Platform)'=='Debug|x64'",
            "#text": "true"
          }
        ],
        "OutDir": "$(SolutionDir)$(Configuration)\\",
        "TargetExt": [
          {
            "-Condition": "'$(Configuration)|$(Platform)'=='Debug|x64'",
            "#text": ".node"
          },
          {
            "-Condition": "'$(Configuration)|$(Platform)'=='Debug|x64'",
            "#text": ".node"
          },
          {
            "-Condition": "'$(Configuration)|$(Platform)'=='Release|x64'",
            "#text": ".node"
          },
          {
            "-Condition": "'$(Configuration)|$(Platform)'=='Release|x64'",
            "#text": ".node"
          }
        ],
        "TargetName": "$(ProjectName)",
        "TargetPath": "$(OutDir)\\$(ProjectName).node"
      }
    ],
    "Import": [
      { "-Project": "$(VCTargetsPath)\\Microsoft.Cpp.Default.props" },
      { "-Project": "$(VCTargetsPath)\\Microsoft.Cpp.props" },
      { "-Project": "$(VCTargetsPath)\\BuildCustomizations\\masm.props" },
      { "-Project": "$(VCTargetsPath)\\Microsoft.Cpp.targets" },
      { "-Project": "$(VCTargetsPath)\\BuildCustomizations\\masm.targets" }
    ],
    "ImportGroup": [
      { "-Label": "ExtensionSettings" },
      {
        "-Label": "PropertySheets",
        "Import": {
          "-Condition": "exists('$(UserRootDir)\\Microsoft.Cpp.$(Platform).user.props')",
          "-Label": "LocalAppDataPlatform",
          "-Project": "$(UserRootDir)\\Microsoft.Cpp.$(Platform).user.props"
        }
      },
      { "-Label": "ExtensionTargets" }
    ],
    "ItemDefinitionGroup": [
      {
        "-Condition": "'$(Configuration)|$(Platform)'=='Debug|x64'",
        "ClCompile": {
          "AdditionalIncludeDirectories": "C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\include\\node;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\src;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\uv\\include;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\v8\\include;%(AdditionalIncludeDirectories)",
          "BasicRuntimeChecks": "EnableFastChecks",
          "BufferSecurityCheck": "true",
          "CompileAsWinRT": "false",
          "DebugInformationFormat": "ProgramDatabase",
          "DisableSpecificWarnings": "4351;4355;4800;4251;%(DisableSpecificWarnings)",
          "ExceptionHandling": "false",
          "MinimalRebuild": "false",
          "OmitFramePointers": "false",
          "Optimization": "Disabled",
          "PrecompiledHeader": "NotUsing",
          "PreprocessorDefinitions": "NODE_GYP_MODULE_NAME=pem;WIN32;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_HAS_EXCEPTIONS=0;BUILDING_V8_SHARED=1;BUILDING_UV_SHARED=1;BUILDING_NODE_EXTENSION;DEBUG;_DEBUG;%(PreprocessorDefinitions)",
          "RuntimeLibrary": "MultiThreadedDebug",
          "StringPooling": "true",
          "SuppressStartupBanner": "true",
          "TreatWarningAsError": "false",
          "WarningLevel": "Level3"
        },
        "Link": {
          "AdditionalDependencies": "kernel32.lib;user32.lib;gdi32.lib;winspool.lib;comdlg32.lib;advapi32.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;odbc32.lib;DelayImp.lib;\"C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\$(Configuration)\\node.lib\"",
          "AdditionalOptions": "/ignore:4199 %(AdditionalOptions)",
          "AllowIsolation": "true",
          "DataExecutionPrevention": "true",
          "DelayLoadDLLs": "iojs.exe;node.exe;%(DelayLoadDLLs)",
          "GenerateDebugInformation": "true",
          "GenerateMapFile": "true",
          "MapExports": "true",
          "OutputFile": "$(OutDir)$(ProjectName).node",
          "RandomizedBaseAddress": "true",
          "SuppressStartupBanner": "true",
          "TargetExt": ".node",
          "TargetMachine": "MachineX64"
        },
        "ResourceCompile": {
          "AdditionalIncludeDirectories": "C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\include\\node;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\src;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\uv\\include;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\v8\\include;%(AdditionalIncludeDirectories)",
          "PreprocessorDefinitions": "NODE_GYP_MODULE_NAME=pem;WIN32;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_HAS_EXCEPTIONS=0;BUILDING_V8_SHARED=1;BUILDING_UV_SHARED=1;BUILDING_NODE_EXTENSION;DEBUG;_DEBUG;%(PreprocessorDefinitions);%(PreprocessorDefinitions)"
        }
      },
      {
        "-Condition": "'$(Configuration)|$(Platform)'=='Release|x64'",
        "ClCompile": {
          "AdditionalIncludeDirectories": "C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\include\\node;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\src;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\uv\\include;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\v8\\include;%(AdditionalIncludeDirectories)",
          "AdditionalOptions": "/MP %(AdditionalOptions)",
          "BufferSecurityCheck": "true",
          "CompileAsWinRT": "false",
          "DebugInformationFormat": "ProgramDatabase",
          "DisableSpecificWarnings": "4351;4355;4800;4251;%(DisableSpecificWarnings)",
          "ExceptionHandling": "false",
          "FavorSizeOrSpeed": "Speed",
          "FunctionLevelLinking": "true",
          "InlineFunctionExpansion": "AnySuitable",
          "IntrinsicFunctions": "true",
          "OmitFramePointers": "true",
          "Optimization": "Full",
          "PrecompiledHeader": "NotUsing",
          "PreprocessorDefinitions": "NODE_GYP_MODULE_NAME=pem;WIN32;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_HAS_EXCEPTIONS=0;BUILDING_V8_SHARED=1;BUILDING_UV_SHARED=1;BUILDING_NODE_EXTENSION;%(PreprocessorDefinitions)",
          "RuntimeLibrary": "MultiThreaded",
          "RuntimeTypeInfo": "false",
          "StringPooling": "true",
          "SuppressStartupBanner": "true",
          "TreatWarningAsError": "false",
          "WarningLevel": "Level3",
          "WholeProgramOptimization": "true"
        },
        "Lib": { "AdditionalOptions": "/LTCG %(AdditionalOptions)" },
        "Link": {
          "AdditionalDependencies": "kernel32.lib;user32.lib;gdi32.lib;winspool.lib;comdlg32.lib;advapi32.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;odbc32.lib;DelayImp.lib;\"C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\$(Configuration)\\node.lib\"",
          "AdditionalOptions": "/ignore:4199 %(AdditionalOptions)",
          "AllowIsolation": "true",
          "DataExecutionPrevention": "true",
          "DelayLoadDLLs": "iojs.exe;node.exe;%(DelayLoadDLLs)",
          "EnableCOMDATFolding": "true",
          "GenerateDebugInformation": "true",
          "GenerateMapFile": "true",
          "LinkTimeCodeGeneration": "UseLinkTimeCodeGeneration",
          "MapExports": "true",
          "OptimizeReferences": "true",
          "OutputFile": "$(OutDir)$(ProjectName).node",
          "RandomizedBaseAddress": "true",
          "SuppressStartupBanner": "true",
          "TargetExt": ".node",
          "TargetMachine": "MachineX64"
        },
        "ResourceCompile": {
          "AdditionalIncludeDirectories": "C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\include\\node;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\src;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\uv\\include;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\v8\\include;%(AdditionalIncludeDirectories)",
          "PreprocessorDefinitions": "NODE_GYP_MODULE_NAME=pem;WIN32;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_HAS_EXCEPTIONS=0;BUILDING_V8_SHARED=1;BUILDING_UV_SHARED=1;BUILDING_NODE_EXTENSION;%(PreprocessorDefinitions);%(PreprocessorDefinitions)"
        }
      }
    ]
  }
}

YAML

Project: 
 ItemGroup: 
  - 
   ProjectConfiguration: 
    - 
   Configuration: Debug
     Platform: x64
     _Include: "Debug|x64"
    - 
   Configuration: Release
     Platform: x64
     _Include: "Release|x64"
   _Label: ProjectConfigurations
  - 
   None: 
    _Include: "..\\binding.gyp"
  - 
   ClCompile: 
    - 
   _Include: "..\\src\\pem.cc"
    - 
   _Include: "C:\\Users\\Kishan Sambhi\\AppData\\Roaming\\npm\\node_modules\\node-gyp\\src\\win_delay_load_hook.c"
 PropertyGroup: 
  - 
   ProjectGuid: "{74CF4537-8047-617D-4D23-0353B4FC702F}"
   Keyword: Win32Proj
   RootNamespace: pem
   IgnoreWarnCompileDuplicatedFilename: true
   PreferredToolArchitecture: x64
   _Label: Globals
  - 
   ConfigurationType: DynamicLibrary
   _Label: Configuration
  - 
   PlatformToolset: v140
   _Label: Locals
  - 
   _Label: UserMacros
  - 
   ExecutablePath: "$(ExecutablePath);$(MSBuildProjectDirectory)\\..\\bin\\;$(MSBuildProjectDirectory)\\..\\bin\\"
   IgnoreImportLibrary: true
   IntDir: "$(Configuration)\\obj\\$(ProjectName)\\"
   LinkIncremental: 
    - 
   _Condition: "'$(Configuration)|$(Platform)'=='Release|x64'"
     __text: false
     toString: 
    - 
   _Condition: "'$(Configuration)|$(Platform)'=='Debug|x64'"
     __text: true
     toString: 
   OutDir: "$(SolutionDir)$(Configuration)\\"
   TargetExt: 
    - 
   _Condition: "'$(Configuration)|$(Platform)'=='Debug|x64'"
     __text: ".node"
     toString: 
    - 
   _Condition: "'$(Configuration)|$(Platform)'=='Debug|x64'"
     __text: ".node"
     toString: 
    - 
   _Condition: "'$(Configuration)|$(Platform)'=='Release|x64'"
     __text: ".node"
     toString: 
    - 
   _Condition: "'$(Configuration)|$(Platform)'=='Release|x64'"
     __text: ".node"
     toString: 
   TargetName: "$(ProjectName)"
   TargetPath: "$(OutDir)\\$(ProjectName).node"
 Import: 
  - 
   _Project: "$(VCTargetsPath)\\Microsoft.Cpp.Default.props"
  - 
   _Project: "$(VCTargetsPath)\\Microsoft.Cpp.props"
  - 
   _Project: "$(VCTargetsPath)\\BuildCustomizations\\masm.props"
  - 
   _Project: "$(VCTargetsPath)\\Microsoft.Cpp.targets"
  - 
   _Project: "$(VCTargetsPath)\\BuildCustomizations\\masm.targets"
 ImportGroup: 
  - 
   _Label: ExtensionSettings
  - 
   Import: 
    _Condition: "exists('$(UserRootDir)\\Microsoft.Cpp.$(Platform).user.props')"
    _Label: LocalAppDataPlatform
    _Project: "$(UserRootDir)\\Microsoft.Cpp.$(Platform).user.props"
   _Label: PropertySheets
  - 
   _Label: ExtensionTargets
 ItemDefinitionGroup: 
  - 
   ClCompile: 
    AdditionalIncludeDirectories: "C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\include\\node;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\src;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\uv\\include;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\v8\\include;%(AdditionalIncludeDirectories)"
    BasicRuntimeChecks: EnableFastChecks
    BufferSecurityCheck: true
    CompileAsWinRT: false
    DebugInformationFormat: ProgramDatabase
    DisableSpecificWarnings: "4351;4355;4800;4251;%(DisableSpecificWarnings)"
    ExceptionHandling: false
    MinimalRebuild: false
    OmitFramePointers: false
    Optimization: Disabled
    PrecompiledHeader: NotUsing
    PreprocessorDefinitions: "NODE_GYP_MODULE_NAME=pem;WIN32;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_HAS_EXCEPTIONS=0;BUILDING_V8_SHARED=1;BUILDING_UV_SHARED=1;BUILDING_NODE_EXTENSION;DEBUG;_DEBUG;%(PreprocessorDefinitions)"
    RuntimeLibrary: MultiThreadedDebug
    StringPooling: true
    SuppressStartupBanner: true
    TreatWarningAsError: false
    WarningLevel: Level3
   Link: 
    AdditionalDependencies: "kernel32.lib;user32.lib;gdi32.lib;winspool.lib;comdlg32.lib;advapi32.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;odbc32.lib;DelayImp.lib;\"C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\$(Configuration)\\node.lib\""
    AdditionalOptions: "/ignore:4199 %(AdditionalOptions)"
    AllowIsolation: true
    DataExecutionPrevention: true
    DelayLoadDLLs: "iojs.exe;node.exe;%(DelayLoadDLLs)"
    GenerateDebugInformation: true
    GenerateMapFile: true
    MapExports: true
    OutputFile: "$(OutDir)$(ProjectName).node"
    RandomizedBaseAddress: true
    SuppressStartupBanner: true
    TargetExt: ".node"
    TargetMachine: MachineX64
   ResourceCompile: 
    AdditionalIncludeDirectories: "C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\include\\node;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\src;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\uv\\include;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\v8\\include;%(AdditionalIncludeDirectories)"
    PreprocessorDefinitions: "NODE_GYP_MODULE_NAME=pem;WIN32;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_HAS_EXCEPTIONS=0;BUILDING_V8_SHARED=1;BUILDING_UV_SHARED=1;BUILDING_NODE_EXTENSION;DEBUG;_DEBUG;%(PreprocessorDefinitions);%(PreprocessorDefinitions)"
   _Condition: "'$(Configuration)|$(Platform)'=='Debug|x64'"
  - 
   ClCompile: 
    AdditionalIncludeDirectories: "C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\include\\node;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\src;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\uv\\include;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\v8\\include;%(AdditionalIncludeDirectories)"
    AdditionalOptions: "/MP %(AdditionalOptions)"
    BufferSecurityCheck: true
    CompileAsWinRT: false
    DebugInformationFormat: ProgramDatabase
    DisableSpecificWarnings: "4351;4355;4800;4251;%(DisableSpecificWarnings)"
    ExceptionHandling: false
    FavorSizeOrSpeed: Speed
    FunctionLevelLinking: true
    InlineFunctionExpansion: AnySuitable
    IntrinsicFunctions: true
    OmitFramePointers: true
    Optimization: Full
    PrecompiledHeader: NotUsing
    PreprocessorDefinitions: "NODE_GYP_MODULE_NAME=pem;WIN32;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_HAS_EXCEPTIONS=0;BUILDING_V8_SHARED=1;BUILDING_UV_SHARED=1;BUILDING_NODE_EXTENSION;%(PreprocessorDefinitions)"
    RuntimeLibrary: MultiThreaded
    RuntimeTypeInfo: false
    StringPooling: true
    SuppressStartupBanner: true
    TreatWarningAsError: false
    WarningLevel: Level3
    WholeProgramOptimization: true
   Lib: 
    AdditionalOptions: "/LTCG %(AdditionalOptions)"
   Link: 
    AdditionalDependencies: "kernel32.lib;user32.lib;gdi32.lib;winspool.lib;comdlg32.lib;advapi32.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;odbc32.lib;DelayImp.lib;\"C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\$(Configuration)\\node.lib\""
    AdditionalOptions: "/ignore:4199 %(AdditionalOptions)"
    AllowIsolation: true
    DataExecutionPrevention: true
    DelayLoadDLLs: "iojs.exe;node.exe;%(DelayLoadDLLs)"
    EnableCOMDATFolding: true
    GenerateDebugInformation: true
    GenerateMapFile: true
    LinkTimeCodeGeneration: UseLinkTimeCodeGeneration
    MapExports: true
    OptimizeReferences: true
    OutputFile: "$(OutDir)$(ProjectName).node"
    RandomizedBaseAddress: true
    SuppressStartupBanner: true
    TargetExt: ".node"
    TargetMachine: MachineX64
   ResourceCompile: 
    AdditionalIncludeDirectories: "C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\include\\node;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\src;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\uv\\include;C:\\Users\\Kishan Sambhi\\.node-gyp\\4.2.2\\deps\\v8\\include;%(AdditionalIncludeDirectories)"
    PreprocessorDefinitions: "NODE_GYP_MODULE_NAME=pem;WIN32;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;_HAS_EXCEPTIONS=0;BUILDING_V8_SHARED=1;BUILDING_UV_SHARED=1;BUILDING_NODE_EXTENSION;%(PreprocessorDefinitions);%(PreprocessorDefinitions)"
   _Condition: "'$(Configuration)|$(Platform)'=='Release|x64'"
 _xmlns: "http://schemas.microsoft.com/developer/msbuild/2003"
 _DefaultTargets: Build
 _ToolsVersion: "14.0"

I think the json is a lot more simple. So, heads up to json! :+1: What do think? You can use this to decide. Happy coding!

Mike-E-angelo commented 8 years ago

Yaml is definitely more concise, that would be my preference from a human-readable perspective. However, a bigger issue here really comes down to tooling (designer-friendly) and additional value-added features, such as markup extensions.

Additionally, the core problem here is that "Project" (the root element) does not translate to an actual CLR object. This is a data (xml) document that is read in and parsed to create a CLR object, which is a terribly inefficient way of using XML, as it not only requires more code, but makes it more difficult to be designer-friendly. So this above all would have to be addressed, first.

In any case, it would be great to see other serialization platforms embrace markup extensions, that would make this conversation easier. :)

Also, while I am dancing around the subject of Xaml, I would like to point out another project that is making its own Xaml engine with all sorts of cool extensions around its binding expressions to make it more developer-friendly. You can see that here: https://grokys.github.io/perspex/perspex-alpha3/

This is a UI-specific implementation of a Xaml engine, OmniXaml, a Xaml-based serializer which can be found here: https://github.com/SuperJMN/OmniXAML/

Gum-Joe commented 8 years ago

Good argument @Michael-DST. I think those issues that you metioned should have been resolved by the time this issue is closed, but thanks for mentioning them. I totally agree with your opinion, but it is harder to see what is grouped together in yaml, whereas in json all you have to do is look for the closing bracket (}). The Xaml projects you mentioned look like it is possible they could be used.

One question: has anyone opened a pull request on this yet, or is it too distant?

Mike-E-angelo commented 8 years ago

Haha... well I say "human-readable" but as we have CLEARLY seen from this thread (and others), it depends on which human is doing the reading. ;)

As for pull requests, not that I know of... just voting and talking. MSBuild team has been worryingly quiet around this discussion.

Gum-Joe commented 8 years ago

Ok :+1:

JohnTasler commented 8 years ago

Thanks, @Gum-Joe, for going through the exercise of converting the msbuild XML to the proposed alternate formats.

However, I really don't find the JSON or YAML to be any more readable than XML. Maybe it's because I've been using XML since the mid-90's. There is tons of tooling already for XML.

Just my opinion.

ghost commented 8 years ago

@JohnTasler, gyp (a build system) configurations (the .gyp files which can also yield dependency configs) are in JSON and they are pretty self descriptive too.

MSBuild can also take inspiration from the way we call / refer script in node.js package.json file, and have an equivalent to Grunt file in C# script to run MSBuild tasks on build events. This will separate nicely and this workflow is working in VS2015 today and developed by by WebDev team at Microsoft. It goes like this:

This means we virtually have a custom build system which can be written in [m]any language[s] and Task Runner will take care of interfacing with MSBuild. No scary MSBuild Tasks and long spaghetti XMLs. :)

This will be cool if MSBuild embrace this concept and come up with more polished conventions for more focused msbuild.json, so we can do everything in JSON explicitly which we are doing in XML.

Mike-E-angelo commented 8 years ago

This will be cool if MSBuild embrace this concept and come up with more polished conventions for more focused msbuild.json, so we can do everything in JSON explicitly which we are doing in XML.

This is all really well and good @jasonwilliams200OK, and I am in agreement with your (general) goal, except that veteran .NET/MSFT developers are saying that the JSON format does not suit them and adds confusion/inconsistency into their current project/solution structures.

I think there's still some confusion regarding JSON vs. "Spaghetti MSBuild XML" (which I am in full agreement that it is). It is spaghetti in that it does not represent a full-fidelity POCO object when serialized, and instead uses XDom-to-POCO mapping, which is a terrible, nasty way to define objects and utilize data within a solution.

I am afraid that the same is the case for your package.json document sample above. Case in point: the -vs-binding property. Does this translate properly to a POCO .NET property? If so, I would like to see how and where. At the very least, there is some (attribute/metadata?) mapping going on as the "-" character is an illegal symbol for a .NET property. This mapping is ultimately just as bad as XDom-to-POCO, because at the end of the day you are dealing with representative, loosely-typed data (higher total cost of ownership) versus serialized, strongly-typed data (lower TCO).

Don't get me wrong, I see the appeal of JSON, but from a veteran MSFT developer point of view it still has a way to go before it beats the likes of Xaml. If you are a new MSFT/web-based developer who hasn't had to do deal with Xaml/MSFT tech, I can understand (and envy) your bliss. However, the veterans here are quite ingrained and satisfied in our approaches and it is this overlooked/neglected fact that is causing the friction in our community right now.

Thank you for your continued dialogue around this matter. :)

Gum-Joe commented 8 years ago

That sounds like a really good idea @jasonwilliams200OK, however, this issue has (unfortunately) been labeled as "distant future" and I can see why. Despite this, we could make our own repo, taking you idea. We could make our own compiler and task runner, using a minimal build.json to specify cpus, tasks and what to compile to where (like popular compilers and task-runners). It could also be cross-language, done by grouping the languages in the build.json. This removes the need for a solution and project file. Here is what I will do: Create a repo called "buildup" and start development of the idea I mentioned above. I will need help with making the compiler.

Happy coding!

Mike-E-angelo commented 8 years ago

Hahah @Gum-Joe trying to make something happen in an open source repo. :) :+1:

Gum-Joe commented 8 years ago

Now live at Gum-Joe/buildup

Gum-Joe commented 8 years ago

:+1:

Mike-E-angelo commented 8 years ago

To be sure, that's: https://github.com/Gum-Joe/buildup

:) :+1:

Gum-Joe commented 8 years ago

Yep :) :+1: