I've been experimenting with using build events to start and stop Windows service that are being built in my project. However for the pre & post builds fail with an error level 255. I've tried catching this with the pre-build with no luck.
Pre-build
if "$(ConfigurationName)" == "Debug"
(
net stop myService
if errorlevel 2
if errorlevel 255
:exit
:exit
)
Post-build
if "$(ConfigurationName)" == "Release"
(
copy $(TargetDir) C:\Media\Bin\$(ProjectName)
if errorlevel 1 BuildEventFailed
:BuildEventFailed
mkdir C:\Media\Bin\$(ProjectName)
copy $(TargetDir) C:\Media\Bin\$(ProjectName)
)
else if "$(ConfigurationName)" == "Debug"
(
net start myService
)
The following weblog by Joel Varty has a solution which I use:
Use Build Events to rebuild a Windows Service without having to manually stop/start it
The only problem is when you do a rebuild. Visual Studio cleans up the files before the pre-build event fires. This then off course fails because the service is still running. But regular builds work great. Hope this helps.
Try using the opening parenthese on the first line of your pre-build code
The conditional statement doesn't require double-qoute ("")
It should be like
if $(ConfigurationName) == Debug (
net stop myService
...
)
This is how I got it to work:
(this solution was a part of an enterprise software where some dll files are reused by another app)
Model is a project which is referenced in Service project and it is built before Service. Which is why we write these codes in Model's Pre-Build Events:
Model Pre-Build Event:
if not exist "$(SolutionDir)UI\bin\Debug\ServiceFolder" mkdir "$(SolutionDir)UI\bin\Debug\ServiceFolder"
net start | find "[Service Name]"
if ERRORLEVEL 0 (
net stop "Service Name"
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe" -u "$(SolutionDir)UI\bin\Debug\ServiceFolder\Service.exe"
)
exit 0
creates a directory in output folder
finds the service by name
stops it
uninstalls it
exit 0 causes the build process to continue if error occurs here
Service Post-Build Event:
xcopy /E /Y "$(ProjectDir)bin\Debug\*" "$(SolutionDir)UI\bin\Debug\ServiceFolder"
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe" "$(SolutionDir)UI\bin\Debug\ServiceFolder\Service.exe"
net start "Service Name"
copy everything needed for the service to a different folder
installs service
starts service
About permissions?
visual studio will ask for elevated permission automatically
Related
I'd like to restart Explorer when building my DLL in Visual Studio. I've tried adding taskkill /f /IM explorer.exe and start explorer as pre-build events in the project configuration. When I then build my project, Explorer will in fact be terminated, but it will not be successfully restarted. The taskbar will remain missing. Only after starting explorer from a command prompt will it return. I've also tried executing a call to those commands in a .bat file, but I get the same problem (although the .bat file works properly when executed on its own, outside Visual Studio). I've also tried putting the relaunch part in a post-build event, but no dice. Is there any trick to getting Explorer to relaunch successfully in a pre-build event? Thanks for any input.
You can restart Explorer by putting the following commands into a Batch file:
#echo off
taskkill /f /im explorer.exe
start explorer.exe
exit
(The /f switch will force the termination of Explorer.)
Then, you can execute that Batch file as a pre-build step (Build Events → Pre-Build Event → Command Line).
If this is a necessary part of your build process, I would recommend adding this Batch file to your solution directory, committing it to your version-control system, and using a relative path in your solution properties.
I am using Visual Studio 2017, but the same behavior was found in Visual Studio 2015.
I have several steps in my post-build events and echo messages in between, like so
echo Copying assets...
xCopy "$(TargetDir)..\..\11 Assets" "$(TargetDir)" /i /s /e /y /q
if $(ConfigurationName) == Debug goto :exit
echo Copying compiled files to release folder...
mkdir "$(TargetDir)_ForRelease"
xCopy "$(TargetDir)App.exe" "$(TargetDir)_ForRelease" /y /q
[...]
Now this all works fine, but what I wanted was to see the echo messages appear one by one in the build output window while the post-build is running (so I know at what step in the post-build I am).
Instead, no messages are displayed during the post-build and instead all messages are displayed as one chunk after the build is completed.
I found one similar question, but it talks about the output window locking up completely, which is not the case here. Everything is responsive, the messages are just not displayed immediately.
Is there a way to solve this and display the messages immediately during the post-build, or is this just how the build process works?
What I ended up doing was using MSBuild directly as an external tool from the toolbar. I basically made a "Build Project" button that calls MSBuild.exe on the solution.
MSBuild shows a command window that prints out the post build steps in real time.
Some of our computers run multiple versions of Microsoft Access (97 & 2010) while others run 365. For the pcs running multiple versions, the default is set to 97. I have a batch file that is performing various tests to see if files exist, and finished by running an Access 2010 database called MWO.accdb. See below.
if exist c:\windows\system32\mscomct2.ocx goto step2
rem copy mscomct2 and register
cscript \\file\apps\Database\Maintenance\365\MsgBox.vbs "Preparing necessary libraries."
copy "\\file\apps\Database\Maintenance\365\mscomct2.ocx" "c:\windows\system32\"
regsvr32 /u mscomct2.ocx
regsvr32 /i mscomct2.ocx
:step2
if exist "%USERPROFILE%\Desktop\MWO.lnk" goto step3
rem create shortcut on user's desktop for future use
cscript \\file\apps\Database\Maintenance\365\MsgBox.vbs "Creating shortcut on desktop & adding to start menu."
copy "\\file\apps\Database\Maintenance\MWO-INSTALL.lnk" "%USERPROFILE%\Desktop\MWO.lnk"
mkdir "%USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu\Maintenance"
copy "\\file\apps\Database\Maintenance\MWO-INSTALL.lnk" "%USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu\Maintenance\MWO.lnk"
:step3
\\file\apps\Database\Maintenance\365\MWO.accdb
Is there an easy way to test for the latest version of access, and force the file to open with it to avoid the defaulting to 97 problem?
wmic product where caption="Access" get caption,version
(I don't have access installed, the captionstring may differ)
I have a test project that builds fine. I am trying to run the tests using mstest. Here is the command I am executing:
Command:
echo mstest.exe /testcontainer:SecurityLogging.Tests\Logging.Tests.dll /resultsfile:%TEST_LOG_ROOT%\Execute_%TestListNode%_1.trx /detail:Owner /detail:Description /nologo /testsettings:Logging.Tests\Local.testsettings /category:"^!E2E&^!Stress&^!Perf"
My tests FAILED. If I then check the error level. It is still 0. I did:
if %errorlevel%==0 (
continue;
)
and it always continues.
I am using Visual Studio 2010. I started digging and I found this:
http://www.mail-archive.com/ccnet-user#googlegroups.com/msg03027.html
Thanks
MSTest is not failing. It executes the tests fine. Your tests are failing and their errors are handled by MStest. So, I think you will not get any %errorlevel%.
I've just confirmed that mstest.exe for Visual Studio 2010 does in fact exit with errorlevel 1 when it runs tests and some of them fail. When all the tests pass, it returns errorlevel 0.
You can verify this with the following lines in your batch file after running mstest:
echo %errorlevel%
pause
If your batch file is being called by another batch file, and you want to pass the errorlevel back, then you can use if not %errorlevel% == 0 exit 1 to shortcut your batch file.
Otherwise, as #Magoo indicates, you may have an unnecessary echo at the front of your call to mstest.exe.
I'm trying to get our build scripts (which use MSBuild) working correctly on Vista and am finding that projects that have the Register Output (in linker options) option set to True fail to build from the command line with something like this:
Project : error PRJ0050: Failed to register output. Please try enabling Per-user Redirection or register the component from a command prompt with elevated permissions.
Although I can easily fix this for a single machine, by running as admin or whatever I want the build script to "just work" for any dev machine.
Even to just fail the registration but have the build continue would be satisfactory. Any suggestions?
Brad
You could create cmd-file that will be contain the following text:
#echo off
call regsvr32.exe /s %1
if %errorlevel% EQU 0 goto ok
echo Fail to register %1
goto exit
:ok
echo Register successful %1
:exit
After that you should switch off registering output and one should add Custom Build Step with command <pathtocmdscript> $(TargetPath). Output one should set to $(TargetPath) for Custom Build Step.
Finally you'll got message about registering progress, but compilation will not stop on that step.