Solution-level packages are no longer working in Visual Studio 2015 RC #522
Comments
mkosieradzki
changed the title
|
This is also known as a tools-only package (package that does not contain any content in the /lib or /content folders within the package). I ran into the same issue and tweeted about it: https://twitter.com/dmccaffery/status/592113002364600320 but never got a response. I hope this isn't an oversight as I rely on this quite heavily (it even sets up my solution folder structure, etc). |
|
@dmccaffery What do you rely on it for? Just curious... |
|
I can say I rely on this feature too: It's really useful to deliver tools for developers in your team or in SDK-like scenarios. It's way more handy than VSIX. Of course it can be replaced by VSIX, but nuget packages are much easier, with nice "init.ps1" semantics, they work on the build server, can be integrated into build process, and of course are much easier to version than VSIX, one they also are way more "agile" as updating powershell-based tools are much easier than complex packages. |
|
I have a package that I apply to an empty solution that creates my solution structure, adds some PowerShell cmdlets to the environment and adds an MSBuild file that sets up everything used for automated builds. It does such things as adding source and test folders, adding StyleCop.Settings files to each, adding R# settings to the solution (team shared), etc. The MSBuild downloads a copy of nuget.exe and calls nuget restore on the solution during build (we point CI build targets to the build.msbuild file instead of the solution file). Lastly, the build stack does semantic versioning automatically and applies the same version to all projects within the solution, which is accomplished by generating an assemblyinfo file. This “could” be done through a package applied at the project level, but it would have some limitations that I do not have today (no way to setup the solution structure, for instance). On May 2, 2015, at 11:21 PM, David Fowler <[email protected]mailto:[email protected]> wrote: @dmccafferyhttps://github.com/dmccaffery What do you rely on it for? Just curious... — |
|
As an FYI: I plan to rework a lot of the automation stuff as build steps to be executed from the new build system in TFS 2015, but it would still be nice to be able to setup the solution structure automatically with a nuget package. Also, the Build.Preview stuff is still in flux, so I cannot rely on it just yet. I used to do this in the old days with a custom project template, but that requires maintenance between different versions of visual studio, etc. Its so much nicer to tell developers to apply a NuGet package to an empty solution and be done with it. |
|
We deprecated solution level packages in NuGet 3.0 and we don't plan to support them going forward. I see what you are trying to do and your thoughts make sense. The alternative beyond what you suggested is to create a powershell script you can point your users to. |
|
Thanks for the update. It shouldn't be too difficult to repurpose this as its primarily PowerShell anyway. Its just not quite as convenient. |
|
Thanks a lot for clarification and a clear statement. In my case I will probably switch to Gulp and it should solve all my issues. So please consider VS 2015 Gulp/Node/Bower/Npm support as a full replacement for solution-level packages in my specific scenario. |
|
Why have solution level packages been deprecated? Was this announced somewhere? Just about everything I work on relies on solution level packages and is now broken! |
|
And would it be fair to say that they have not just been "deprecated"? It would seem that the feature has in fact been removed. |
|
Yes it was removed. We do think this was not a good decision and we are devising a way to bring it back in a more sane way. The alternative in Visual studio 2015 is to put packages in a project. |
|
It's become a non-issue for me, as it just doesn't make any sense in the world of DNX. For the MsBuild project system, I was able to write a PowerShell module to handle scenarios where I used to use solution level packages. In reality, a solution-level package in its previous implementation was nothing more than a dump of assets and a PowerShell script that gave you an opportunity to do something with those assets -- if you didn't, the solution level package was useless. |
|
@dmccaffery the utility of solution level packages is wider than that. I use it for a number of tools packages, e.g test runners. Incidentally, in most of my OSS projects, PowerShell is a no-go since they x-plat from the ground up. Yet I still find solution level packages very useful in those projects. |
|
Adam - you can put these packages in a project now. There is a downside (which is why we will bring it back) where the project wont round trip with vs 2013. From: Adam Ralphmailto:[email protected] @dmccafferyhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fdmccaffery&data=01%7c01%7cyigalatz%40microsoft.com%7ce1a99a94a2fb48c76b4108d2ccd79546%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=U6A7RA4ptBLRvOPn%2bjlJ9%2bcDkegrgdMgp2IwYck%2fqLQ%3d the utility of solution level packages is wider than that. I use it for a number of tools packages, e.g test runners. Incidentally, in most of my OSS projects, PowerShell is a no-go since they x-plat from the ground up. Yet I still find solution level packages very useful in those projects. — |
|
That's probably enough of a downside for me to keep using 2.x until it's been reintroduced to 3.x. Even without that downside, it's not logical for these packages to be installed in a project. They are almost always used to operate on the solution as a unit, e.g .NuGet.CommandLine to restore all packages, or on a group of projects, e.g. xunit.runner.console to run against a group of test assemblies. |
|
I get your point. A few pieces of feedback: The idea is that you put it in some common project. Also using restore as part of msbuild is broken for many packages and we recommend using nuget in a pre build script. It mostly impacts packages using msbuild targets. From: Adam Ralphmailto:[email protected] That's probably enough of a downside for me to keep using 2.x until it's been reintroduced to 3.x. Even without that downside, it's not logical for these packages to be installed in a project. They are almost always used to operate on the solution as a unit, e.g .NuGet.CommandLine to restore all packages, or on a group of projects, e.g. xunit.runner.console to run against a group of test assemblies. — |
|
The common project pattern feels messy. What if I don't already have one? Would I create one specifically for this purpose? I don't use restore as part of MSBuild. I use NuGet.CommandLine to restore in a pre-build script. I do this by committing |
|
This makes complete sense. I didn't realize people are using the command line package this way. The reason this is not so great with git I that many people frown on checking binaries in a git repo. So bootstrapping is the mechanism we favor and recommend, and why we introduced the latest download link (initially on nuget.org/nuget.exe and now the more obvious one on dist.nuget.org). When it comes to solution level packages I'm convinced we should bring it back, but I want it back in a less arbitrary way than how it worked in 2013 (where packaged got moved to solution level based on content) and have an explicit model. Unfortunately I don't yet see it making to 3.3, and probably yes in the release right after that. I'll open a clean issue on this subject and move it to the discussions milestone. So we can have a specific discussion on the new design. From: Adam Ralphmailto:[email protected] The common project pattern feels messy. What if I don't already have one? Would I create one specifically for this purpose? I don't use restore as part of MSBuild. I use NuGet.CommandLine to restore in a pre-build script. I do this by committing packages/Nuget.CommandLine to the repo, but I ignore the rest of packages/. I realise I could put NuGet.exe in it's own special folder or even bootstrap a download of it in my pre-build script, but it feels natural to be using the NuGet package. Anyway, it's just one example of a solution level tools package. There are plenty more. — |
|
@yishaigalatzer thanks, that sounds good. I'll watch the new issue and chime in if I can add anything. I like the idea of making it explicit, rather than based on sniffing the content. In the case of NuGet.exe, the bootstrapping approach is indeed compelling and I may switch to it. Incidentally, when using a .NET based build system, such as Bau, the bootstrapping comes for free, since NuGet.CommandLine may be declared as a dependency of the build script, e.g. https://github.com/colored-console/colored-console. |
|
For anyone watching this thread, the new issue is at #1521 |
|
Thanks @adamralph forgot to add the link From: Adam Ralph [mailto:[email protected]] For anyone watching this thread, the new issue is at #1521https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fNuGet%2fHome%2fissues%2f1521&data=01%7c01%7cyigalatz%40microsoft.com%7c19defd1ab40249db074308d2ce14804e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ouQ3MSr%2fkaQcblTPRBqRz6xtFbDXuYl%2fHxZK6MTX41E%3d — |
…o change it -_- The .nuget\packages.config is also obsolete (because it still does not work for VS2015!) and replaced on .gnt (GetNuTool) Related issues: * NuGet/Home#522 * NuGet/Home#1521
I have a solution level package consisting of powershell commands and some tools that I am successfully using in Visual Studio 2013. It was created with nuget 2.8.50506.491,
It does not work in VS 2015 RC. Is it as designed? Should I add new special configuration to .nuspec to allow solution-level or are the solution-level packages deprecated at all? Or maybe should I repack.
I found some information that there is a "new UI" that solves solution-level packages issues. In my case it proposes to install solution-level package to all projects separately.
The text was updated successfully, but these errors were encountered: