Visual Studio 2010 post build event completely ignored - msbuild

I was looking on stackoverflow for anything similiar to my issue but without results.
It seems that my VS started to completely ignore post-build events.
Post-build events are not triggered in any project or solution I open
or create using my VS 2010.
I don't know why and from when, but previously (a couple of weeks ago) it was working fine. And I haven't changed project configuration nor VS installation on my own. There were a couple of windows update though, but since I dont know from when it is not working, I can not specify them. I want post-build event to be triggered, but it never is, no matter how simple it is. The project configuration is fine, since it is working for my team mates (on their machines).
Trying to figure out what is happening, I did:
created test project
disabled all plugins (CodeMaid, VSAssistX, etc.)
created pre-build, pre-link and post-build events that simply echo something (and ofcourse enabled them in project properties (Use in build -> Yes)).
The result is that I see echos and VS messages about pre-build and pre-link build event, but nothing about post-build event (btw I'm using Qt add-in):
1>------ Rebuild All started: Project: Test, Configuration: Debug Win32 ------
1>Build started 2013-02-07 11:03:54.
1>_PrepareForClean:
1> Deleting file "Debug\Test.lastbuildstate".
1>InitializeBuildStatus:
1> Creating "Debug\Test.unsuccessfulbuild" because "AlwaysCreate" was specified.
1>PreBuildEvent:
1> prebuild
1>CustomBuild:
1> Moc'ing Test.hpp...
1> Uic'ing Test.ui...
1> Rcc'ing Test.qrc...
1>RCC : warning : No resources in 'C:\Projects\BuildEvents\Test\Test\Test.qrc'.
1>
1>ClCompile:
1> moc_Test.cpp
1> main.cpp
1> Test.cpp
1> Generating Code...
1> qrc_Test.cpp
1>PreLinkEvent:
1> prelink
1>qtmaind.lib(qtmain_win.obj) : warning LNK4099: PDB 'vc100.pdb' was not found with 'qtmaind.lib(qtmain_win.obj)' or at 'C:\Projects\BuildEvents\Test\vc100.pdb'; linking object as if no debug info
1> Test.vcxproj -> C:\Projects\BuildEvents\Test\Test.exe
1>FinalizeBuildStatus:
1> Deleting file "Debug\Test.unsuccessfulbuild".
1> Touching "Debug\Test.lastbuildstate".
1>
1>Build succeeded.
1>
1>Time Elapsed 00:00:02.80
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========
I suspect that problem is with Visual Studio itself, but maybe you have any better ideas what might be causing that and how to solve it?

Finally I just created script that I run manually after each build. This is stupid solution, because when any of my teammates will do some changes that require changes in post-build, I will need to change my script too.

Related

console application is not building in vs 2019

I am constantly this error in debug mode.
Severity Code Description Project File Line Suppression State Error MSB3027 Could not copy "C:\Users\N3617\Source\Repos\Core\CoreData\ConsoleApp1\obj\Debug\netcoreapp3.1\ConsoleApp1.exe" to "bin\Debug\netcoreapp3.1\ConsoleApp1.exe". Exceeded retry count of 10. Failed. The file is locked by: "ConsoleApp1 (1080)" ConsoleApp1 C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets 4643
I had to restart system to get rid off this error. Can anyone tell why is this happening?
It seems an old problem that your project is locked by some other process due to some reasons. You can see this similar issue.
It is complex to explain that but you can try the following steps if you faced them next time:
Suggestion
1) open Task Manager--> shut down ConsoleApp1.exe process, any dotnet process, NET Core Host process or similar process every time when you faced this issue and then build your project again.
2) close VS, delete .vs hidden folder under solution folder, bin and obj folder and then restart VS
3) enter Tools-->Options-->Projects and Solutions-->Build and Run-->set maximum numbers of parallel project builds to 1.
4) uncheck option Use Managed Compatibility Mode under Tools-->Options-->Debugging-->General

Dotfuscator says "was expecting one of:" when building in Visual Studio

I've got a solution in Visual Studio that includes a Dotfuscator project. The exact same code base builds and obfuscates correctly on another machine (my old laptop), but not on my newly setup laptop. Of course we let our support contract expire since this is used on a legacy project.
The output during the build is:
8>Compiling Project MyAppObfuscation ...
8>Dotfuscator Professional Version 4.41.1.9417-95d9eec7a
8>Copyright 2002-2019 PreEmptive Solutions, LLC All Rights Reserved.
8>Use of this software implies acceptance of accompanying license agreement.
8>Build machine license. This software may be used on binaries for general release.
8>
8>Your protection is out of date. Learn more at https://www.preemptive.com/keep-your-protection-up-to-date?product=dotfuscator&sku=pro&version=4.41.1.9417. Upgrade at https://www.preemptive.com/products/dotfuscator/downloads.
8>
8>Loading Assemblies...
---several of these lines---
8>Running ...\ildasm.exe /OUT=...\MyApp.exe.il /TEXT /NOBAR /RAWEH /QUOTEALLNAMES /UTF8 /LINENUM /FORWARD "...\MyApp.exe"
8>
--- immediately followed by: ---
8>Encountered - at line 18065, column 26.
8>Was expecting one of:
8> <FLOAT64> ...
8> "float64" ...
8> "float32" ...
8> <INT> ...
8> "(" ...
8>
8>Build Error.
8>MyAppObfuscation build failed.
Has anyone encountered this? I'm inclined to believe it's something on the new machine, but if anyone has tips about diagnosing this I would appreciate it.
Thanks!
Edit: Just wanted to add the same error happens in Visual Studio and the Dotfuscator Professional Config Editor.
Edit 2: Upon further inspection, the folder listed in the /OUT parameter of ildasm doesn't contain a .il file for the last ildasm command. The output folder for the assemblies prior to the .exe DO have a .il file. So, I thought ildasm might be failing on the .exe, but I can copy the command into a command prompt and it runs correctly and creates an .il file as expected. So, why would ildasm not work when run from Visual Studio, but would work from the command line -- and only for one assembly / exe in the project?
The mystery grows...
Solved it! I opened Visual Studio Installer on both the old and new machine to compare what features were installed on the old one vs the new one. Most notably, one of the missing features on the Individual components tab was an older .NET Framework SDK (4.6.1 in my case) and an older Windows 10 SDK (10.0.17763.0 in my case).
I hope someone else finds this helpful.

SonarQube 5.6 - MSBuild Fakes Generation failing (SonarQube.Integration.targets)

I posted a similar question here.
Unfortunately, this issue is coming up again after having upgraded our build machines to run on Visual Studio Online 2015's Build and Release Manager.
This is the error that I get from a solution that generates Fakes assemblies used in unit testing:
D:\builds\TFS2015agent_2_work\1\.sonarqube\bin\targets\SonarQube.Integration.targets(240,5):
error MSB3491: Could not write lines to file "D:\builds\TFS2015agent_2_work\1\.sonarqube\out\\f_AnyCPU_Release_9840\FilesToAnalyze.txt".
The process cannot access the file 'D:\builds\TFS2015agent_2_work\1\.sonarqube\out\f_AnyCPU_Release_9840\FilesToAnalyze.txt' because it is being used by another process. [D:\builds\TFS2015agent_2_work\1\s\FakesFilePath\f.csproj] [D:\builds\TFS2015agent_2_work\1\s\FakesFileProj]
2016-09-13T20:01:37.6477261Z GENERATEFAKES : error : project compilation failed with exit code 1 [D:\builds\TFS2015agent_2_work\1\s\FakesFilePath\]
Does anyone have an idea of why this is happening? What process is causing the error? Could it possibly be related to the fakes compiling while SonarQube tries to access it?

The mystery of stuck inactive msbuild.exe processes, locked Stylecop.dll, Nuget AccessViolationException and CI builds clashing with each other

Observations:
On our Jenkins build server, we were seeing lots of msbuild.exe processes (~100) hanging around after job completion with around 20mb memory usage and 0% CPU activity.
Builds using different versions of stylecop were intermittently failing:
workspace\packages\StyleCop.MSBuild.4.7.41.0\tools\StyleCop.targets(109,7):
error MSB4131: The "ViolationCount" parameter is not supported by the "StyleCopTask" task.
Verify the parameter exists on the task, and it is a gettable public instance property.
Nuget.exe was intermittently exiting with the following access violation error (0x0000005):
.\workspace\.nuget\nuget install .\workspace\packages.config -o .\workspace\packages"
exited with code -1073741819.
MsBuild was launched in the following way via a Jenkins Matrix job, with 'BuildInParallel' enabled:
`msbuild /t:%Targets% /m
/p:Client=%Client%;LOCAL_BUILD=%LOCAL_BUILD%;BUILD_NUMBER=%BUILD_NUMBER%;
JOB_NAME=%JOB_NAME%;Env=%Env%;Configuration=%Configuration%;Platform=%Platform%;
Clean=%Clean%; %~dp0\_Jenkins\Build.proj`
After a lot of digging around and trying various things to no effect, I eventually ended up creating a new minimal solution which reproduced the issue with very little else going on. The issue turned out to be caused by msbuild's multi-core parallelisation - the 'm' parameter.
The 'm' parameter tells msbuild to spawn "nodes", these will remain alive after the build has ended, and are then re-used by new builds!
The StyleCop 'ViolationCount' error was caused by a given build re-using an old version of the stylecop.dll from another build's workspace, where ViolationCount was not supported. This was odd, because the CI workspace only contained the new version. It seems that once the StyleCop.dll was loaded into a given MsBuild node, it would remain loaded for the next build. I can only assume this is because StyleCop loads some sort of singleton into the nodes processs? This also explains the file-locking between builds.
The nuget access violation crash has now gone (with no other changes), so is evidently related to the above node re-use issue.
As the 'm' parameter defaults to the number of cores - we were seeing 24 msbuild instances created on our build server for a given job.
The following posts were helpful:
msbuild.exe staying open, locking files
http://www.hanselman.com/blog/FasterBuildsWithMSBuildUsingParallelBuildsAndMulticoreCPUs.aspx
http://stylecop.codeplex.com/discussions/394606
https://github.com/Glimpse/Glimpse/issues/115
http://msdn.microsoft.com/en-us/library/vstudio/ms164311.aspx
The fix:
Add the line set MSBUILDDISABLENODEREUSE=1 to the batch file which launches msbuild
Launch msbuild with /m:4 /nr:false
The 'nr' paremeter tells msbuild to not use "Node Reuse" - so msbuild instances are closed after the build is completed and no longer clash with each other - resulting in the above errors.
The 'm' parameter is set to 4 to stop too many nodes spawning per-job
I had the same issue. One old reference I found was in csproj files
<PropertyGroup>
<StyleCopMSBuildTargetsFile>..\packages\StyleCop.MSBuild.4.7.48.0\tools\StyleCop.targets</StyleCopMSBuildTargetsFile>
Also, I deleted the entire "Packages" folder that's located in the same folder as sln file after I closed the visual studio. It triggered VS to rebuild the folder and let go of the cache of the old version of stylecop
I've had the same issue for a while, builds were taking over 6 minutes to finish after some digging I found our it's node reuse fault so adding /m:4 /nr:false fixing my issue immediately

help building castle dynamic proxy

So I pulled the source from https://svn.castleproject.org/svn/castle/DynamicProxy/trunk/
Open it up in vs.net 2008
problems:
vs.net can't open the assembly.cs
assembly signing failed
What am I doing, rather NOT doing?
Update
So I downloaded nant, setup the .bat file in my PATH so it works in cmd prompt.
I ran:
nant default.build
Getting this error:
build failed, \buildscripts\common-project.xml (48,3)
invalid element . Unknown task or datatype.
How exactly do I build the dynamicProxy project now?
update
This is what I did, see screenshot:
oh and my nant is:
#echo off
"E:\dev\tools\nant-bin\nant-0.86-nightly-2009-05-05\bin\Nant.exe" %*
http://img697.imageshack.us/img697/5623/castlebuildscreenshot.png http://img697.imageshack.us/img697/5623/castlebuildscreenshot.png
You can read the FM (how to build.txt). :)
You need to run the build script first using NAnt (http://nant.sf.net). This will generate the assembly.cs file. Take a look at the .build files in the tree to see what they are doing.
As for the assembly signing failing, check the project settings to get rid of references to CastleKey.snk. It should sign it using DynProxy.snk (in theory).
UPDATE:
The issue with NUnit is now fixed. Do a clean check out. I really have no idea why you're getting that error. Which version of NAnt are you using? Make sure you have the latest (earlier do not have support for .NET 3.5)
You should be able to just pull the source from the trunk, and build with nant (I just did that and it worked). Ok, I lied, looks like the reference to NUnit is wrong, so the unit test project will not build correctly:
BUILD FAILED - 0 non-fatal error(s), 1 warning(s)
D:\OLD\DynamicProxy\buildscripts\common-project.xml(295,5):
'nunit-console.exe' failed to start.
The system cannot find the file specified
Total time: 1.2 seconds.
BUILD FAILED
Nested build failed. Refer to build
log for exact reason.
Total time: 3.4 seconds.
However the important stuff (assemblyinfo generation) will succeed and you should be able to just open Castle.DynamicProxy2-vs2008.sln, fix the reference to the NUnit assembly hit F5 and build the code with no issues.
I just did it on a clean check out, and it worked.
Generally if you're planning to do modifications in DP codebase, it is advised to go to the Castle user group first, and discuss it there.