how to manage locked files

Apr 3, 2011 at 10:19 AM

I want to use nuget to deploy an MSBuild task

The problem is that after the first build VS will lock the assembly containing the task.

So how do I manage this with nuget? Is it possible to have nuget detect locked files and recommend a VS restart? Similar to the approach taken by visual studio extensions.

Apr 4, 2011 at 1:07 PM


Apr 4, 2011 at 6:37 PM

You might be able to do that in your install.ps1 file, but I have no clue how to do that. You could simply output a message recommending an install if the build task doesn't work and let the user figure it out. Not great, but I don't have a clue otherwise.

Apr 5, 2011 at 10:43 PM

So I guess my question is: Is this something NuGet will eventually look at doing? Or should I go and build a bunch of workarounds?

Also should I raise a feature request for it?

Apr 5, 2011 at 10:55 PM

File a bug and try to get it voted up.

Apr 5, 2011 at 11:00 PM


Apr 5, 2011 at 11:04 PM

You should still look into workarounds. There's no guarantee we'll do this for the next release.

Jul 26, 2011 at 8:43 AM

I have re-opened the issue because I can see no feasible way to solve this given the current state of how nuget works

Basically the files are locked by visual studio and install.ps1 runs from within visual studio. So unless I am missing something this is not possible for me to solve without changes to Nuget.

Am I incorrect?

Jul 26, 2011 at 8:44 AM

You can copy the file to a temp directory and load it from there.

Jul 26, 2011 at 9:29 AM

So there are two scenarios for managing an msbuild task assembly.

1 Stored under the solution so it can be checked in to source control

eg $(SolutionDir)Tools\MyMsBuildTask.dll

2 Stored somewhere globally

eg D:\Tools\BuildTasks\MyMsBuildTask.dll


In case 1 placing MyMsBuildTask.dll in a temp dir does not update the current instance of VS to the new file. Nor does it overwrite the "checked-in" file so it can be picked up by source control and checked in. I could modify the csprojto point to the temp dir, but this would effectively break the source control approach.

In case 2 we have the same "current instance will not update" and also have other issues since MyMsBuildTask.dll may be locked by multiple instances of VS

So this is the current hack I have had to use this approach
The problem is it effectively kills the users ability to update the package.