Hy guys,
for a project at the university we're faced with the following problem:
For coverage analysis purposes we should instrument the code of several C++-Projects, which are automatically build via a VBScript using devenv. Before the actual build process we have to add 3 things:
A new VC++-Directory, with the path to the Cl-Wrapper.exe which does the instrumentation (needs to be first entry).
Additional command line commands for the C\C++-Compiler.
Additional command line commands for the Linker.
We tried to solve this via an Add-In, launched through the /Command switch for devenv. Sadly this doesn't work. After a little search, we found thats MSBuild might solve our problem via an additional configuration. For me it looks like that this could be done only for a certain project. But we are looking for a project independent way to execute the 3 stepa above before the build process.
Is there any possibility to achieve this with devenv/MSBuild?
Thanks so far..
Related
We noticed that on a certain dev machine a Visual Studio (2015 update 3) debug build of a C# solution was generating a $RANDOM_SEED$ file alongside every built DLL.
The content of the file is just a single number e.g.
1443972318
Deleting the file(s) then rebuilding resulted in the file being regenerated, with a different number.
This behaviour was also observed when rebuilding a single project in the solution (one which has only the standard C# project refs/dependencies + System.Management).
Note that running a command line build e.g.
msbuild <sln-file>
did not regenerate the file (for build of complete solution or single project).
After a restart of VS, the file is no longer regenerated.
As far as we know this file name is not used in any of our source code, post build steps or internal dependencies.
There are quite a few dependencies on .NET framework classes, including Random and RNGCryptoServiceProvider, and also external dependencies. We don't have complete source code for all these so it's not possible to check exhaustively which if any of the dependencies are responsible.
This is a bit of a shot in the dark but the question is has anyone seen anything similar to this?
EDIT
I'm not surprised this has been downvoted - I appreciate it is pretty open ended, but as I'm currently not able to reproduce this and as it could have potentially serious consequences (random number generator attack?) I have posted it anyway. If I am able to repro I will of course update here.
I have the same file.
After a short investigation I found guilty:
this file is created by NUnit 3.x test adapter.
(You can check it in AdapterSettings.cs from NUnit adapter source code).
The file is used by NUnit to ensure that we use the same random seed value for generating random test cases in both the discovery and execution processes. This is required because the IDE uses two different processes to execute the adapter. It's not actually required (or created) when running the adapter under vstest.console.exe.
I have a build process (let's call it the "engine") that has been using a command line call to Visual Studio's devenv.exe to build a project. I have known for some time that VS is just building with MSBuild, so I finally got around to updating the engine to use MSBuild directly. However, I'm finding a strange anomaly with MSBuild.
For the sake of discussion, there's projects A, B, C, and D. Project A is the main project I'm building, a web app, that depends (through project references) on the other 3 projects. When built manually in VS, A\bin is populated with assemblies. When built in the engine with devenv.exe A\bin is again populated with the expected binaries. When built in the engine use MSBuild, A\bin contains nothing. However, B\Release\bin, C\Release\bin and D\Release\bin contain their binaries as they did using the former 2 build methods.
This happens with just a single project as well. The problem doesn't appear to be related to dependent projects.
I have attempted to explicitly set the MSBuild OutDir property, but it doesn't appear to have any affect.
I have run builds with diagnostic output on and can't see anything obvious (granted, there is a LOT there so it's possible I have yet to find something significant).
I've also been trying to figure out how to see the command line call to MSBuild that VS is making when run from devenv.exe but I can't seem to find it.
I have looked at several other SO posts (here and here) but they aren't the same problem.
Anyone have an idea of what this could be or where else I could look for an answer or more diagnostic information?
EDIT 1: The arguments pattern used for the call to MSBuild looks like this:
/nologo /target:Compile /property:Configuration=%%BUILDCONFIG%% /maxcpucount
/property:OutDir=%%OUTDIR%%\bin\ /verbosity:diag /detailedsummary "%%PROJPATH%%"
The lower half of that shows my attempt to force the output directory as well as the enhanced output to show more details of the process. Build engine code replaces with "%%TOKEN%%" items with the appropriate replacement values for the project being built.
EDIT 2: After more research and looking into suggested provided, I've decided to abandon the effort to use msbuild instead of devenv. It seems there is a lot more going on under the hood of devenv in preparation its own call to msbuild and I could likely break something else going on if I don't fully understand the entrance in msbuild. I did try to see if the call to msbuild from devenv is logged, but it doesn't seem to be. I've considered building a dummy msbuild app to just dump the command going into it and temporarily swap out the actual msbuild to generate this diagnostic information, but that's more effort than it's worth at this point. The performance gain isn't so great that it's worth pursuing further for now.
I would look at the Output path on the build tab of your project properties. There are more than few differences when using MSBuild and when using Visual Studio (Even from the command line). It could be you have A configured differently than B,C,D and synching A to the rest will make it work. Also, if you plan to build the projects individually, not as a solution make sure you don't use Solution Level macros that won't be available to the project file on it own.
You are supposed to set OutputPath instead of OutputDir.
Since you already used /verbosity:diag, why not redirect the output to a text file and carefully analyze where csc.exe (or another compiler in use) stores the binaries? That's quite simple and informative for you to learn how MSBuild works under the hood.
I have a solution with several projects in it that executes many custom build steps. Some projects depend on other projects, but most of the build steps are independent of each other.
When building inside the VS 2010 IDE, I am getting errors like this:
error MSB6003: The specified task executable "cmd.exe" could not be run. The process cannot access the file 'C:\full\path\Debug\custombuild.write.1.tlog' because it is being used by another process
However, when I build the solution with MSBuild from the command line, all is well, and the log file writing does not seem to cause the same error.
Is this a known issue? Google has not been much help today...
The answer was hinted at in an MSBuild forum thread.
The custom build rule logs are written into the containing project's $(IntDir). We had multiple projects (with no real output being sent to IntDir) that all inadvertently shared the same IntDir value. Giving each project its own IntDir value eliminated the problem.
I wrote a small tool which sits in my solution (as a project), which runs in the background and helps me debug my main project.
I'd like to run the tool with a macro but I haven't found how to get the build path and execute it in the background.
Any VB macro experts ?
To answer your question partly, apparently you can get the solution path from within a macro like this:
System.IO.Path.GetDirectoryName(DTE.Solution.FullName)
I found this in some of the macros listed here. Since you say you've got a project within that solution, you could try DTE.Solution.FindProjectItem and progress from there. It's difficult to give more information without knowing more details about your exact scenario.
So this is a question for anyone who has had to integrate the building/compilation of legacy projects/code in a Team Build/MSBuild environment - specifically, Visual Basic 6 applications/projects.
Outside of writing a custom build Task (which I am not against) does anyone have any suggestions on how best to integrate compilation and versioning of legacy VB6 projects into MSBuild builds?
I'm aware of the FreeToDev msbuild tasks at CodePlex but they've been withdrawn at the moment.
Ideally I'm looking to version and compile the code as well as capture the compilation output (especially errors) for the msbuild log.
I've seen advice on encapsulating this functionality in a custom task, but really wondered if anyone has tried another solution (aside from executing shell commands) -
In essence, does anyone have a "cleaner" solution?
Ideally, executing commands using would be a last resort..
The VB6 task will be back on Monday. With regards to versioning, there is no explicit vb versioning task in the pack, however you could make use of the TfsVersion (TaskAction="GetVersion") and the File (TaskAction="Replace") tasks. If you think there is value in creating a new task to encapsulate / provide other functions, then please let me know and I will add it to the pack for the benefit of the whole community.
Apologies for the withdrawal, but come Monday I'm sure all will understand.
I am using Nant to build VB6 projects daily. This does resort using the Nant execute command to do the builds (we build 4 projects as part of one "solution").
It also allows you to label versions in your source control repository, get latest code, check in, check out, all the normal requirements, compile the update/setup programs copy the files to required locations and send emails of the results.
The logged results are fairly minimal though as you only get the output provided by a VB6 command line compile.
For versioning, I had to write a small app to extract the version number of my compiled executable and write it to a text file that Nant could then read and use (for labels, file names etc. (A bit of a pain but VB generated version numbers don't comply anyway).
For help with other non-core tasks see NAntContrib - from the NAnt link above.