When I move my package (dll) to a nuproj's project reference, dependecies arent add. How can I add them?
it's just the tooling is missing so much...
freaking xproj returns
.NETFramework,Version=v4.5.1 for `GetTargetFrameworkMoniker, even though it's supposed be netstandard1.6
bloody liar :no_good:
We get the "Value can not be null" #212 all the time, and it would be nice if I could tell the team members just to pull the latest version from Visual Studio Gallery
I've been using Nuget.Package.Builder (a Nuget package by Lars Skovlund) which turns any class library project into a Nuget packager producer for years. So you only have one project, not two. Is there any benefit of NuProj over Package Builder?
His approach adds a bunch of MSBuild code via a .targets file. I really like the purer approach that NuProj takes, but its a pity that it needs that extra project for every Nuget package (unless I'm woefully misunderstanding something)
Oh, and for open source stuff I've been using AppVeyor to create and push the packages
@yannduran: each nuproj produces one nupkg (or two, if you build a symbols package). So if you have a collection of class libraries, you can either bundle them up in a single package with one nuproj, or you can create a nuproj for each class library to get one for each (or anywhere in between).
If you always package one dll per nupkg and you're happy with other csproj injection techniques to add packaging to a library project, that's fine. NuProj is targeting folks who want more control of packaging and its contents.
With the VS2017 .NET Core project type, libraries know how to package themselves and that may be a great option for you as well, but I personally can't migrate several of my packages to it because it's not flexible enough, so I stick with NuProj for those.
If you always package one dll per nupkg and you're happy with other csproj injection techniques to add packaging to a library project, that's fine. NuProj is targeting folks who want more control of packaging and its contents.
With the VS2017 .NET Core project type, libraries know how to package themselves and that may be a great option for you as well, but I personally can't migrate several of my packages to it because it's not flexible enough, so I stick with NuProj for those.
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