Background:
I'm working on two projects in visual studio 2015 - one that produces a file (I'll call it "Generator"), and one that uses said file at runtime (I'll call it "Consumer").
What I want to do:
I'm currently working on the file produced by Generator. In order to see how Consumer is affected after modification of Generator I have to:
Build and run Generator,
Switch startup project to Consumer,
Build and run Consumer,
Switch startup project back to Generator.
I'd like to have all of this done in a single Ctrl+F5.
What I've tried to do:
In the solution properties->startup project there is an option called "Current selection" that makes this tedious process a bit faster, but this is only a partial solution.
I tried to use "multiple startup projects", but this approach isn't for me - it runs these projects simultaneously and I want Consumer to wait until Generator is done.
In my most succesful approach I made a .bat that runs Generator and added it to one of build steps in Consumer (doesn't really matter what step - I used "prebuild event"). I also added Generator to Consumer's Build Dependencies. It works perfectly when I modify both Generator and Consumer. The problem appears when I modify Generator only - in such case build of Consumer doesn't trigger at all - which means that my bat file won't run Generator (I think that Consumer should be build, because dependent project was modifed).
What I don't want to do:
My solution contains other projects, some of which take long time to build - I don't want to rebuild whole solution or any projects other that the two I was talking about.
Answer to this question isn't for me - I don't want to alter Consumer only to simplify the building process, because Generator is merely a utility to create some file used in the main program (Consumer). On the other hand I don't mind adding some additional projects.
To summarize:
If you know how to force project to be rebuild when it's dependency is out of date I'd be happy. If you know any other way to deal with my problem I'd be happy either.
I found a "how did I not think about it before?" kind of solution:
Since I want to run Generator after it's modification I in fact want to run it after it's build. So instead of trying to run it in Consumer's build i do this as Generator's Post-build Event.
Related
I have a visual studio solution with multiple projects. One generates code files as part of pre-build (grpc classes via Grpc.Tools). There is also a shared project that extends the partial classes built as part of that pre-build.
However, sometimes for one reason or another - like compiling the client half of this (client uses the shared project to extend its own classes), compilation will error because the shared project can't find the generated classes yet. Presumably they don't exist. It's fixed easily by compiling the project twice.
Is there something I can do in this scenario? Is it possible to somehow move validating/compiling the shared project "further down" the compilation pipeline? Or even just set that particular project to try and compile twice if there's an error? Or is this the kind of thing that realistically I should just live with given what I'm doing - I haven't found any other references to this problem. It's not that big of an issue and it wouldn't happen very often, but I'd like to handle it reasonably if I can.
Edit
If I wasn't clear, this is a shared project, as in a .shproj, a project that is not compiled separately. The project that references it includes it and builds it all together as one.
If project B depends on project A, then project A must be built before project B. Visual Studio is smart enough to figure out the build order this way. Incidentally, this is also one of the reasons (among many) why circular dependencies simply cannot work.
I suspect that your projects are currently not linked via a dependency, as this issue wouldn't occur if there were such a link. Perhaps your second project is accessing the first project's files via the file system? That's just a guess though.
You can use this "A before B which depends on A" behavior of the build process to your advantage. Have project B (i.e. the project you need to go second) add project A (i.e. the project you need to go first) as a dependency. This forces VS to build them in the appropriate order.
Some remarks:
I am unsure if VS is able to omit dependencies that you add but not actually depend on (i.e. you never reference its content). I can't find any confirmation on this point (but absence of proof is not proof of absence!) But even if that is the case, that could be easily worked around by having a dummy class in B which actually references and uses something from project A.
Keep in mind that during a regular build, VS does not rebuild projects that have not changed since the last build. If this is an issue for you (unsure if it is, you didn't add enough context), make sure to always rebuild or clean to make sure that a new build will be triggered.
However, sometimes for one reason or another - like compiling the client half of this (client uses the shared project to extend its own classes), compilation will error because the shared project can't find the generated classes yet. Presumably they don't exist. It's fixed easily by compiling the project twice.
That it is only sometimes and can be fixed by "trying again" points at one thing - you got race condition. But a race condition during compilation, is not a thing I heard off or encountered before.
I got a few possible cultripts. But in the end, race conditions are notoriously hard to debug:
- Maybe the compiler that deals with the shared project returns before it is finished - wich should be impossible - or
- Maybe something causes the main projects to compile before the shared projects files are ready.
- Maybe a 3rd party tool - like a Virus scanner or auto backup maker inteferes?
- Maybe the shared projects compiled files are hosted on a network drive, and there sometimes is just the slightest delay between "compiled" and "visible to all other computers in the network"?
Usually the proper ways for dependant compilation should deal with such issues. That indicates that what you got there, is propably not the most stable setup.
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 am working on a c++ solution which contains 20 projects. My first project builds and I run it as a pre-build event for rest of the projects. Now this executable actually creates some c++ files which should get added to all the other projects which are yet to be compiled. How should I do this? (Using VS2008)
Here are few solutions I thought.
Solution 1:
Let the exe update the vcproj file for all the remaining projects. But in this case as the project is on in VS, it creates some reload popup which I dont want. So is there any way to suppress this popup and just save the changes.
Solution 2:
Visual Automation:
I was just going through some automation API.
The solution and project interface methods would help in adding new file. But will it not create a new pop up as the previous on? Can I use MSbuild here?
You can simply use Generated_*.cpp (or similar pattern) as name of items for corresponding group in project. Than when project is build it will pick up all matching files, even once generated during pre-build steps.
If number of files is small you can just add them to the project directly (which I believe is ok even if they are missing before build).
Note that it may be good idea to generate files into separate folder (like obj\....) so you don't run into cases when someone mistakenly checks in generated files.
I have a little program I wrote to download all NuGet packages for a solution. I would like to setup a pre-build event that would run this program every time I build.
But I need it to run before the first project starts to build. I could look at what is currently building first, and put it on that project's pre-build event, but that is fairly brittle. Any time I add a new project or update references between projects, I would have to double check that the "first" building project is still the first one.
So, what I really need is a way to do this before any building really starts. I have heard of Visual Studio macros. But those are not something that gets checked in so I would prefer to not use those (but if that is my only option, I would use them).
You could try this: http://sedodream.com/2010/10/22/MSBuildExtendingTheSolutionBuild.aspx
Unfortunately it only works called from the command line via MSBuild. Seems to be a design flaw that the behaviour is different and these events are not available via the IDE.
You could also modify your base MSBuild tasks to include the action based on a specific flag/file existence/solution name, but this is all sorts of evil.
Otherwise, you are pretty stuck with a prebuild on each project.
I call nuget install from the prebuild event for any project that uses nuget packages. It is smart enough to only download packages that have not already been downloaded.
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.