← Back to team overview

coapp-developers team mailing list archive

Re: CoApp 2.4.493.0 installs overlay packages in the wrong place when NuGet.exe is in PATH


Oh. My…

In the short run, you can unlist/unpublish your package (they can never be deleted) which should solve the short-term issue.

My goal was to make sure that C++ packages would use the latest version of the NuGet client, so we could roll with the changes. I didn’t think that they could break something.

I’m going to have to take a look into this—I’m catching up on stuff all week, but I’ll see what I can do.

I may need to get those broken packages from you so I can experiment.


From: Coapp-developers [mailto:coapp-developers-bounces+garretts=microsoft.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Gonçalo Lopes
Sent: Sunday, April 27, 2014 7:59 PM
To: coapp-developers@xxxxxxxxxxxxxxxxxxx
Subject: [Coapp-developers] CoApp 2.4.493.0 installs overlay packages in the wrong place when NuGet.exe is in PATH

Hey guys,

I've recently updated to the latest version of CoApp development (2.4.493) and I started experiencing a weird behavior with overlay packages.

I first built a native package with overlays and verified that it deployed fine under all platform/architecture/configuration combinations.

In preparation for pushing to the NuGet gallery, I updated my NuGet.exe in the PATH to the latest release and set the API key.

After this step I pushed everything to NuGet and retried the installation from the remote server.

To my surprise, I started getting this warning: "warning : Overlay Package 'OpenCV.overlay-Win32_v110_Debug v2.4.9' installed correctly, but the nupkg file 'c:\Users\Gonçalo\documents\visual studio 2012\Projects\ConsoleApplication6\packages\OpenCV.2.4.9\OpenCV.overlay-Win32_v110_Debug.2.4.9.nupkg' is not in the expected location."

Basically for some reason the overlay packages got installed in the directory where the ".csproj" is, rather than the package root directory. Also predictably the build failed since files were not where they were supposed to be.

After painfully backtracking all my steps, I traced the cause down to my upgraded version of NuGet.exe in PATH.

Apparently CoApp uses either the NuGet client that comes with the package or the one in PATH, whichever has the largest version. When the NuGet client embedded in the package was the highest version, everything was fine. However, when I upgraded the NuGet.exe in my PATH, CoApp started using that and then I got this behavior.

I verified this was the case by removing NuGet from the PATH and retrying the installation: it works. If I put it back in the PATH again, I go back to this weird behavior.

I already confirmed I get this with both VS 2012 and 2013. Any idea what could cause this behavior at all?

Why should the overlay install location change depending on where the NuGet client is?

For now I'm trying to get the NuGet support team to retract my package, but this is a big source of concern, since it may mean deployment can break depending on machine configuration...

By the way, the NuGet version in PATH was 2.8.1.

Hope you can help me out. Thanks,