The change to the item type was probably an oversight on my part. IIRC XamlPropertyRule causes code generation to run for each rule. If I got away with the mistake, I guess we didn't depend on the code generation -- although we should, in order to avoid magic strings in our code.
get rid of the MSI, keep only 2017 .vsix, update refences to MSBuild 15.0
but I didn't realize you were waiting for me to finish #286
so, how about this:
then merge #286, I'll remove support for old VS, and then release .vsix and and updated packages for MSBuild 15.0
not dealing with 2013/2015 should make easier to figure out, what's up with this https://github.com/nuproj/nuproj/issues/266#issuecomment-289991188
Oh dear
Sounds like a plan
We would really appreciate, like really really, if you could do a service release for Visual Studio 2015
so that we can get rid of the "Value can not be null" #212 problem, which you fixed in oktober, but not released yet
before you abandon VS2015 for VS2017
We are not able to upgrade our toolchain to VS2017 just yet, as we are still missing some other tools that not work with 2017 yet
How are we going to handle the VSIXs? Are there separate VSIXs for 2015 and 2017? I assume the answer is yes, otherwise we cannot support side-by-side servicing.
How are we going to handle this in the NuGet package?
so this is what I would do:
1) release from current master, nuproj.msi, nuproj.nupkg and nuproj.common.nupkg as 0.12.X
1) release from current master, nuproj.msi, nuproj.nupkg and nuproj.common.nupkg as 0.12.X
2) branch it
3) change dependencies to MSBuild 15.0, consolidate code to 2017 VSIX, get rid of MSI and 2013/2015 VSIXs
4) release nuproj.2017.vsix, nuproj.nupkg and nuproj.common.nupkg as 0.13.X
Is there any example?