0

I build a windows service in c# .net. I added Pre-Build and Post-Build event to automatically deploy my service on the build. But sometime I got this error :

Unable to copy file "[CompletPath...]\bin\Debug\Business.Data.dll" to "bin\Debug\Business.Data.dll". The process cannot access the file 'bin\Debug\Business.Data.dll' because it is being used by another process.

In the Pre-Build event i'm closing the service, killing all task that using file in the Debug directory and uninstalling the service. There is the code in the .bat that i'm running in the Pre-Build event :

SET executionPath=%~dp0
SET serviceName=%1
SET frameworkPath=%2
SET targetServicePath=%3
SET targetBinPath=%~4
set targetBinPath=%targetBinPath:~0,-2%

net stop %serviceName%
powershell -NonInteractive -executionpolicy Unrestricted -file "%executionPath%\unlockfiles.ps1" "%targetBinPath%"
%frameworkPath%\installutil.exe /u %targetServicePath%

Exit /b 0

On the post-build event i'm installing and starting the service, there is the code even if this is not the problem because i'm gettring the error on the build, so the post-build event is not executing.

SET serviceName=%1
SET frameworkPath=%2
SET targetServicePath=%3

%frameworkPath%\installutil.exe /ShowCallStack %targetServicePath%
net start %serviceName%

I'm not always having the problem. I usually have the problem the first time i'm building, i'm cleaning the solution, build again and usually it's working after this.

Marc-André Bilodeau-Lamontagne
  • 888
  • 3
  • 11
  • 32

2 Answers2

1

I would separate these processes if I were you. You don't need to uninstall the service in order to update the files.

I'm not a great fan of pre/post build events for much more than moving some files around after the build has completed.

I use xcopy /y /c "$(TargetPath)" "location to copy to"

If memory serves I didn't even actually have to stop the service in order to update the dlls, however you may need to just stop the service in the post build before doing the xcopy commands.

Jammer
  • 9,969
  • 11
  • 68
  • 115
  • I changed my setup to do something like this but it's not better. I'm killing all the process in the directory where my files are copied (killing it with handle.exe), copying the file, but some files are still locked. Even if i'm killing every processes with handle.exe... BUT if i'm killing those process, waiting 30 secondes and copying after this small sleep. Everything is working fine... – Marc-André Bilodeau-Lamontagne May 01 '13 at 14:31
  • Just out of interest are you installing and running this service from within VS to test it? If so, I'd consider moving to using unit tests so you can test WITHIN Visual Studio and build a complete installer using WiX for deployment. Visual Studio is not really a deployment tool which is what you're trying to turn it into with your process. – Jammer May 01 '13 at 14:53
  • I'm uninstalling my service in the pre-build event and installing it in the post-build event. My goal is not to test my service, what I want to do is automatically update the windows service when some one is building the project. The main reason for this is because we are 5 to work in the same solution and when someone is editing the service, we all want to have the service up to date on our computer. At first we were manually updating it, but it's a pain in the ass to always tell everyone to update the service every time your are editing it. That's why we want to automate the process. – Marc-André Bilodeau-Lamontagne May 01 '13 at 15:20
  • I'm going to add another answer for this. – Jammer May 01 '13 at 20:42
0

If I were in your situation I would start to employ and more team oriented solution.

I would spend some time setting up a Continuous Integration system using something like Team City (this tool is free for upto 20 build configurations. I REALLY rate everything from JetBrains.

Then each time one of your team checks in new source code for the service it will be detected automatically by the build system (Team City) and a new set of builds will be triggered.

You could have a debug build that runs your unit tests against the code, a release build that also then includes a WiX Project that also then builds an installer for the service.

Once those processes are completed you can configure it to pop the installer in a known location on your network and it can also then email all the developers in your team to notify them that a new version of the service is available for installation.

WiX is a VERY mature installation authoring tool that is used by Microsoft for a lot of their products. There is a lot of support out there for the tool set and will make your entire process much tighter, repeatable and predictable.

It will take some time to get all of this completed but it really is worth the effort.

Jammer
  • 9,969
  • 11
  • 68
  • 115
  • We are already using team city and using it to deploy the new version on QA, Staging and Demo environements. The windows service is automaticly deploy with Team-city... But the main problem is for our local computer... We don't want to run the installer each time something change. We are 5 dev and in 1 day we have like 10-15 check-in. Thanks a lot for all this help. – Marc-André Bilodeau-Lamontagne May 02 '13 at 17:47
  • Ahhh OK, Another thing to try might be to compile the service into a location that ISN'T a \bin\Debug or \bin\Release directory and install from there. I've had issues with Visual Studio having handles on files in these locations in the past and moving them all to another location within your solution directory tree (eg: \Service\) can fix them. No problem on the help :) – Jammer May 02 '13 at 18:06
  • Ya that's exactly what I finally done... Like you suggest me, I'm copying the file to another folder, and installing the service from there... But in the Pre-Build event, I still need to have a sleep of +/- 20 seconds after stopping the service and killing all the processes (With handle.exe) before being able to copy the file... – Marc-André Bilodeau-Lamontagne May 03 '13 at 02:23
  • Yeah, that doesn't really surprise me to be honest, I'm sure windows takes a while to spool the service down and release the file locks even though your `net stop` command has 'completed'. Glad you got it sorted. – Jammer May 03 '13 at 06:28