Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 01 2019 22:54
    AArnott closed #307
  • Oct 01 2019 22:54
    AArnott labeled #307
  • Oct 01 2019 22:54
    AArnott commented #307
  • Oct 01 2019 22:24
    ndrwrbgs commented #307
  • Sep 10 2019 14:31
    AArnott commented #307
  • Sep 10 2019 11:24
    RonenGlants commented #307
  • Aug 02 2019 14:43
    docwattsman commented #303
  • Aug 02 2019 14:39
    docwattsman commented #303
  • Jun 10 2019 21:26
    AArnott closed #309
  • Jun 10 2019 21:26
    AArnott commented #309
  • Jun 10 2019 21:26
    AArnott labeled #309
  • Jun 10 2019 21:23
    jerchap opened #309
  • May 21 2019 23:22
    AArnott closed #308
  • May 21 2019 23:22
    AArnott commented #308
  • May 21 2019 23:22
    AArnott labeled #308
  • May 21 2019 21:42
    AleRoe opened #308
  • Apr 24 2019 17:49
    ErikApption opened #307
  • Feb 14 2019 16:28
    joepeavey commented #297
  • Feb 14 2019 16:28
    joepeavey commented #297
  • Feb 13 2019 20:25
    joepeavey commented #297
Christoph Lindemann
@ChristophLindemann
Any idea on when the next release will be? One that is published to Visual Studio Gallery?
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
Andrew Arnott
@AArnott
I confess, after seeing so much action on NuProj in so little time, I've been afraid to review all the github notifications for it for lack of time.
Pavol Kovalik
@kovalikp
Well, I actually fixed the issue with resolving references in CPS, so it might be good idea release new version.
Andrew Arnott
@AArnott
awesome. :)
Andrew Arnott
@AArnott
going through my backlog of nuproj notifications now.
Christoph Lindemann
@ChristophLindemann
@kovalikp & @AArnott any closer to releasing a new version?
Andrew Arnott
@AArnott
@ChristophLindemann No. I'm hoping to have time before new year's. But I can't guarantee anything at this point.
Yann Duran
@yannduran
hi guys. i love the idea of this project, but correct me if I'm wrong but there has to be a separate nuproj for each class library as a nuget package?
Yann Duran
@yannduran

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

Zihao Chen
@amat27
Hi guys. is there a way to add empty dependency group in nuproj?
Andrew Arnott
@AArnott
@amat27 Yes. it involves adding a nuspec file to your nuproj project that nuproj's build then uses as a template for the nuspec it constructs.
@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.
Yann Duran
@yannduran
@AArnott Thanks Andrew!
Pavol Kovalik
@kovalikp
@AArnott about that PowerShell - MSBuild integration I mentioned some while ago: got it working
Andrew Arnott
@AArnott
cool. I remember a couple times since you talked about it, wishing it was around.
Pavol Kovalik
@kovalikp
Pavol Kovalik
@kovalikp
@AArnott are the XamlPropertyRule items required to be compiled? I just noticed when you moved .xaml files to shared project, you changed XamlPropertyRule items to None, but it did not seem to have any adverse effect.
Andrew Arnott
@AArnott
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.
Pavol Kovalik
@kovalikp
my thought process here:
I want to deprecate support for 2013/2015 and only release for 2017
get rid of the MSI, keep only 2017 .vsix, update refences to MSBuild 15.0
Andrew Arnott
@AArnott
I'm OK with that. We can keep a vs5015 branch in case we need to service it.
Pavol Kovalik
@kovalikp
which is significant breaking change, so making NuProj.2017, NuProj.Common.2017 would make a sense
but I didn't realize you were waiting for me to finish #286
so, how about this:
Pavol Kovalik
@kovalikp
could you release current master, that should at least have that Project reference error that we have like 10 different bugs for
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
Andrew Arnott
@AArnott
but I didn't realize you were waiting for me to finish #286
Oh dear
Sounds like a plan
Pavol Kovalik
@kovalikp
least have fixed that Project reference
Christoph Lindemann
@ChristophLindemann
Hey guys
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
Immo Landwerth
@terrajobst

@kovalikp
I want to deprecate support for 2013/2015 and only release for 2017
get rid of the MSI, keep only 2017 .vsix, update refences to MSBuild 15.0

Makes sense to me too.

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?
Pavol Kovalik
@kovalikp
@terrajobst in #286 there is MSI containing 2013 + 2015 VSIXs, while 2017 VSIX is standalone
so this is what I would do:
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
Pavol Kovalik
@kovalikp
5) service 2013/2015 from branch as 0.12.Y (if that ever happen)
Andrew Arnott
@AArnott
I've finally shipped the vs2015 branch to nuget.org and the VS Marketplace. It's version 0.11.28-beta. @kovalikp Please feel free to merge your PR when ready.
Andrew Arnott
@AArnott
I've also bumped the version in master branch from 0.11.x to 0.20.x.
Yongli Chen
@saiyan86
Hey guys! How do I include vc runtime to the nuproj?
Is there any example?