New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Solution-level packages are no longer working in Visual Studio 2015 RC #522

Closed
mkosieradzki opened this Issue May 2, 2015 · 21 comments

Comments

Projects
None yet
5 participants
@mkosieradzki

mkosieradzki commented May 2, 2015

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.

@mkosieradzki mkosieradzki changed the title from Solution-level packages are not longer working in Visual Studio 2015 RC to Solution-level packages are no longer working in Visual Studio 2015 RC May 2, 2015

@dmccaffery

This comment has been minimized.

Show comment
Hide comment
@dmccaffery

dmccaffery May 2, 2015

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 commented May 2, 2015

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).

@davidfowl

This comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl May 3, 2015

Member

@dmccaffery What do you rely on it for? Just curious...

Member

davidfowl commented May 3, 2015

@dmccaffery What do you rely on it for? Just curious...

@mkosieradzki

This comment has been minimized.

Show comment
Hide comment
@mkosieradzki

mkosieradzki May 3, 2015

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.

mkosieradzki commented May 3, 2015

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.

@dmccaffery

This comment has been minimized.

Show comment
Hide comment
@dmccaffery

dmccaffery May 3, 2015

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 <notifications@github.commailto:notifications@github.com> wrote:

@dmccafferyhttps://github.com/dmccaffery What do you rely on it for? Just curious...


Reply to this email directly or view it on GitHubhttps://github.com/NuGet/Home/issues/522#issuecomment-98441406.

dmccaffery commented May 3, 2015

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 <notifications@github.commailto:notifications@github.com> wrote:

@dmccafferyhttps://github.com/dmccaffery What do you rely on it for? Just curious...


Reply to this email directly or view it on GitHubhttps://github.com/NuGet/Home/issues/522#issuecomment-98441406.

@dmccaffery

This comment has been minimized.

Show comment
Hide comment
@dmccaffery

dmccaffery May 3, 2015

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.

dmccaffery commented May 3, 2015

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.

@yishaigalatzer

This comment has been minimized.

Show comment
Hide comment
@yishaigalatzer

yishaigalatzer May 4, 2015

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.

yishaigalatzer commented May 4, 2015

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.

@dmccaffery

This comment has been minimized.

Show comment
Hide comment
@dmccaffery

dmccaffery May 4, 2015

Thanks for the update. It shouldn't be too difficult to repurpose this as its primarily PowerShell anyway. Its just not quite as convenient.

dmccaffery commented May 4, 2015

Thanks for the update. It shouldn't be too difficult to repurpose this as its primarily PowerShell anyway. Its just not quite as convenient.

@mkosieradzki

This comment has been minimized.

Show comment
Hide comment
@mkosieradzki

mkosieradzki May 4, 2015

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.

mkosieradzki commented May 4, 2015

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.

@adamralph

This comment has been minimized.

Show comment
Hide comment
@adamralph

adamralph Oct 3, 2015

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!

adamralph commented Oct 3, 2015

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!

@adamralph

This comment has been minimized.

Show comment
Hide comment
@adamralph

adamralph Oct 3, 2015

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.

adamralph commented Oct 3, 2015

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.

@yishaigalatzer

This comment has been minimized.

Show comment
Hide comment
@yishaigalatzer

yishaigalatzer Oct 3, 2015

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.

yishaigalatzer commented Oct 3, 2015

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.

@dmccaffery

This comment has been minimized.

Show comment
Hide comment
@dmccaffery

dmccaffery Oct 3, 2015

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 commented Oct 3, 2015

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.

@adamralph

This comment has been minimized.

Show comment
Hide comment
@adamralph

adamralph Oct 4, 2015

@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.

adamralph commented Oct 4, 2015

@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.

@yishaigalatzer

This comment has been minimized.

Show comment
Hide comment
@yishaigalatzer

yishaigalatzer Oct 4, 2015

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:notifications@github.com
Sent: ‎10/‎4/‎2015 9:19 AM
To: NuGet/Homemailto:Home@noreply.github.com
Cc: Yishai Galatzermailto:yigalatz@microsoft.com
Subject: Re: [Home] Solution-level packages are no longer working in Visual Studio 2015 RC (#522)

@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.


Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fNuGet%2fHome%2fissues%2f522%23issuecomment-145363644&data=01%7c01%7cyigalatz%40microsoft.com%7ce1a99a94a2fb48c76b4108d2ccd79546%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=e4C7f5kNHlsafrHzZVLd%2bVPRe%2bLamC9dN8VUm0ElHgo%3d.

yishaigalatzer commented Oct 4, 2015

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:notifications@github.com
Sent: ‎10/‎4/‎2015 9:19 AM
To: NuGet/Homemailto:Home@noreply.github.com
Cc: Yishai Galatzermailto:yigalatz@microsoft.com
Subject: Re: [Home] Solution-level packages are no longer working in Visual Studio 2015 RC (#522)

@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.


Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fNuGet%2fHome%2fissues%2f522%23issuecomment-145363644&data=01%7c01%7cyigalatz%40microsoft.com%7ce1a99a94a2fb48c76b4108d2ccd79546%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=e4C7f5kNHlsafrHzZVLd%2bVPRe%2bLamC9dN8VUm0ElHgo%3d.

@adamralph

This comment has been minimized.

Show comment
Hide comment
@adamralph

adamralph Oct 4, 2015

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.

adamralph commented Oct 4, 2015

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.

@yishaigalatzer

This comment has been minimized.

Show comment
Hide comment
@yishaigalatzer

yishaigalatzer Oct 4, 2015

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:notifications@github.com
Sent: ‎10/‎4/‎2015 11:34 AM
To: NuGet/Homemailto:Home@noreply.github.com
Cc: Yishai Galatzermailto:yigalatz@microsoft.com
Subject: Re: [Home] Solution-level packages are no longer working in Visual Studio 2015 RC (#522)

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.


Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fNuGet%2fHome%2fissues%2f522%23issuecomment-145371604&data=01%7c01%7cyigalatz%40microsoft.com%7c25eb036cc3e64d44784e08d2ccea7471%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Kw0ClyKF3d7t%2bhhLq86jibEWvz22CpZML5MCTaunRhQ%3d.

yishaigalatzer commented Oct 4, 2015

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:notifications@github.com
Sent: ‎10/‎4/‎2015 11:34 AM
To: NuGet/Homemailto:Home@noreply.github.com
Cc: Yishai Galatzermailto:yigalatz@microsoft.com
Subject: Re: [Home] Solution-level packages are no longer working in Visual Studio 2015 RC (#522)

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.


Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fNuGet%2fHome%2fissues%2f522%23issuecomment-145371604&data=01%7c01%7cyigalatz%40microsoft.com%7c25eb036cc3e64d44784e08d2ccea7471%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Kw0ClyKF3d7t%2bhhLq86jibEWvz22CpZML5MCTaunRhQ%3d.

@adamralph

This comment has been minimized.

Show comment
Hide comment
@adamralph

adamralph Oct 4, 2015

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.

adamralph commented Oct 4, 2015

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

This comment has been minimized.

Show comment
Hide comment
@yishaigalatzer

yishaigalatzer Oct 4, 2015

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:notifications@github.com
Sent: ‎10/‎4/‎2015 12:05 PM
To: NuGet/Homemailto:Home@noreply.github.com
Cc: Yishai Galatzermailto:yigalatz@microsoft.com
Subject: Re: [Home] Solution-level packages are no longer working in Visual Studio 2015 RC (#522)

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.


Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fNuGet%2fHome%2fissues%2f522%23issuecomment-145377566&data=01%7c01%7cyigalatz%40microsoft.com%7c209e640999874bef272708d2cceecafd%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=x5eN5M6WmTKIeQUcJ5vRflvHho3xVHVAavL3y%2fF%2bsyI%3d.

yishaigalatzer commented Oct 4, 2015

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:notifications@github.com
Sent: ‎10/‎4/‎2015 12:05 PM
To: NuGet/Homemailto:Home@noreply.github.com
Cc: Yishai Galatzermailto:yigalatz@microsoft.com
Subject: Re: [Home] Solution-level packages are no longer working in Visual Studio 2015 RC (#522)

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.


Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fNuGet%2fHome%2fissues%2f522%23issuecomment-145377566&data=01%7c01%7cyigalatz%40microsoft.com%7c209e640999874bef272708d2cceecafd%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=x5eN5M6WmTKIeQUcJ5vRflvHho3xVHVAavL3y%2fF%2bsyI%3d.

@adamralph

This comment has been minimized.

Show comment
Hide comment
@adamralph

adamralph Oct 4, 2015

@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.

adamralph commented Oct 4, 2015

@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.

@adamralph

This comment has been minimized.

Show comment
Hide comment
@adamralph

adamralph Oct 6, 2015

For anyone watching this thread, the new issue is at #1521

adamralph commented Oct 6, 2015

For anyone watching this thread, the new issue is at #1521

@yishaigalatzer

This comment has been minimized.

Show comment
Hide comment
@yishaigalatzer

yishaigalatzer Oct 6, 2015

Thanks @adamralph forgot to add the link

From: Adam Ralph [mailto:notifications@github.com]
Sent: Monday, October 5, 2015 11:08 PM
To: NuGet/Home Home@noreply.github.com
Cc: Yishai Galatzer yigalatz@microsoft.com
Subject: Re: [Home] Solution-level packages are no longer working in Visual Studio 2015 RC (#522)

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


Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fNuGet%2fHome%2fissues%2f522%23issuecomment-145750276&data=01%7c01%7cyigalatz%40microsoft.com%7c19defd1ab40249db074308d2ce14804e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UO9WL9I7ycBnaaLQWGLpuLdnGyjW5BWBmTet%2fag3fX8%3d.

yishaigalatzer commented Oct 6, 2015

Thanks @adamralph forgot to add the link

From: Adam Ralph [mailto:notifications@github.com]
Sent: Monday, October 5, 2015 11:08 PM
To: NuGet/Home Home@noreply.github.com
Cc: Yishai Galatzer yigalatz@microsoft.com
Subject: Re: [Home] Solution-level packages are no longer working in Visual Studio 2015 RC (#522)

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


Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fNuGet%2fHome%2fissues%2f522%23issuecomment-145750276&data=01%7c01%7cyigalatz%40microsoft.com%7c19defd1ab40249db074308d2ce14804e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UO9WL9I7ycBnaaLQWGLpuLdnGyjW5BWBmTet%2fag3fX8%3d.

@programcsharp programcsharp referenced this issue Oct 23, 2015

Open

VS 2015 #2

3F added a commit to 3F/vsSolutionBuildEvent that referenced this issue Feb 7, 2016

fixed build: avoids version for CI.MSBuild package /I always forget t…
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment