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.
For some reason when I open my project Compile button is disabled. I'm in C++ file and Ctrl+F7 doesn't work, Menu/Build/Compile is disabled and Compile in context menu in SolutionExplorer is disabled too. I can build project with F7, but I can't compile single file. It used to work just fine.
Any ideas why?
Had the same problem just because my project wasn't set as startup Project in my solution. Setting it solve the issue.
It seems that problem is on my side: someone in my team introduced some build scripts, which apparently work only for building whole project.
It might also be that a referenced property sheet could not be found. You can check this by attempting to view the properties of the project (Alt-Enter). A warning will be shown then when the property sheet cannot be found. Fix the property sheet reference, and probably you can compile again.
Note: question was asked/answered a while ago, but maybe it is useful for other persons.
My project was using an intermediate version of a unity build (sometimes called blob build) where groups of ~10 cpp files are put in the same compilation unit by being included in some blob_xxx.cpp. The project only considers the blob_xxx.cpp as source files, so technically the .cpp I was working on was not a source file for the project, so the Compile command was disabled (this is similar to what Paulius experienced).
In this case, you need to either select the blob_xxx.cpp file and Compile this single file, or switch to a non-blob build.
If your objective is to quickly test for compilation errors, you can comment out the includes for all the files you are not working on.
Alternatively, you may setup your project generation script to isolate the files you are working on in a separate blob (it's up to you to define what "working on" means; it may be a manual list or the list of cpp files that are checked out in Perforce if using it).
Hey, I use a Pre-build event to call an external compiler to compile an opencl kernel. This way i get all the errors messages inside the ide. But if you only change the kernel, the compiler is not required to run so there is no pre-build event, even if the kernel compile command would generate an error. So is there a way to run the command before you execute your program instead? Like a Pre-Run event ;)
You can have your pre-build target add the item to the inputs list I think it is. Once Visual studio is clued in to check those files for modification, it will know to trigger your Target. I'm not sure that it will actually Invoke a pre-build, so you may want to hook into another target as a BeforeTargets attribute.
Your project file will typically have a Imports on some targets files, that should give you somewhere to start searching for which Target is appropriate.
Another possibility is to add your target to the default targets list at the top of the proj file.
how-to-invoke-the-same-msbuild-target-twice-with-different-parameters-from-within reference may help.
I have a Visual Studio project that uses a solution file to build it. I want to generate a makefile so that I can build it using the makefile instead of the solution file. (The reason I need to do this in case you are wondering is that I am incorporating my project into a larger software system that uses makefiles to build, and I want to be able to build the whole thing using the makefiles.)
Is there a way to automatically get the information from the Visual Studio solution and convert it into a makefile format, or do I need to do that manually?
This used to be possible in VC6, it had an option to generate a makefile from a .dsp project file. No more, the build process has changed too much to make this achievable.
Not a real problem, you can have the makefile invoke the vcbuild.exe tool, it builds a .vcproj project. Important switches you'll want to use in your makefile:
/clean: use that in your clean: target
/rebuild: use in your rebuild: target
/nocolor: makes build output look battleship gray like other build tools
/platform: selects the configuration you want to build (e.g: /platform:win32)
For example:
vcbuild /platform:win32 example.vcproj release
Note that the build system got a major revision in VS2010, you'll use msbuild.exe instead to build the .vcxproj project.
Although I never used it, this might be an alternative. It's rather old and might not work well for new projects. It used to come with mingw but (don't know why) not anymore. Offtopic: Personally, if the project is not enormous, I would go with manually writing a Makefile.
Good advice - Avoid wasting a couple of days on tools for a job that'll take a few hours at most. They guy who built my first house had one 30 year old table saw and built the whole house iwth it. I now have at least 10 saws and never build anything.
I know the ideal way to build projects is without requiring IDE based project files, since it theoretically causes all sort of trouble with automation and what not. But I've yet to work on a project that compiles on Windows that doesn't depend on the VisualStudio project (Ok, obviously some Open Source stuff gets done with Cygwin, but I'm being general here).
On the other hand if we just use VS to run a makefile, we loose all the benefits of the compile options window, and it becomes a pain to maintain the external makefile.
So how do people that use VS actually handle external makefiles? I have yet to find a painless system to do this...
Or in reality most people don't do this, although its preached as good practice?
Take a look at MSBuild!
MSBuild can work with the sln/csproj files from VS, so for simple projects you can just call them directly.
if you need more control, wrap the projects in your own build process, add your own tasks etc. - it is very extensible!
(I wanted to add a sample but this edior totally messed up the XML... sorry)
Ideally perhaps, in practice no.
Makefiles would be my preference as the build master, however, the developers spend all their time inside the visual studio IDE and when they make a change, it's to the vcproj file, not the makefile. So if I'm doing the global builds with makefiles, it's too easily put out of synch with the project/solution files in play by 8 or 10 others.
The only way I can stay in step with the whole team is to run devenv.exe on the solution files directly in my build process scripts.
There are very few makefiles in my builds, where there are they are in the pre-build or custom build sections or a separate utility project.
One possibility is to use CMake - you describe with a script how you project is to be built, and CMake generates the Visual Studio solution/project files for you.
And if you need to build your project from the command line, or in a continuous integration tool, you use CMake to generate a Makefile for NMake.
And if you project is a cross-platform one - you can run CMake to generate the makefiles for the toolchain of your choice.
A simple CMake script looks like this:
project(hello)
add_executable(hello hello.cpp)
Compare these two lines with a makefile or the way you setup a simple project in your favorite IDE.
In a nutshell CMake does not only cross-platform-enables your project it also makes it cross-IDE. If you like to just test your project with eclipse or KDevelop, or codeblocks, just run CMake to generate the corresponding project files.
Well, in practice it is no always so easy, but the CMake idea just rocks.
For example, if you consider using CMake with Visual Studio there is some tweaking required to obtain the familiar VS project feeling, main obstacle is to organize your header and source files, but it is possible - check the CMake wiki (and by writting a short script you might even simplify this task).
We use a NAnt script, which at the compile step calls MSBuild. Using NAnt allows us to perform both pre- and post-build tasks, such as setting version numbers to match source control revision numbers, collating code coverage information, assembling and zipping deployment sources. But still, at the heart of it, it's MSBuild that's actually doing the compiling.
You can integrate a NAnt build as a custom tool into the IDE, so that it can be used both on a build or continuous integration server and by the developers in the same way.
Personally, I use Rake to call msbuild on my solution or project. For regular development I use the IDE and all the benefits that provides.
Rake is set up so that I can just compile, compile and run tests or compile run tests and create deployable artifacts.
Once you have a build script it is really easy to start doing things like setting up continuous integration and using it to automate deployment.
You can also use most build tools from within the IDE if you follow these steps to set it up.
We use the devenv.exe (same exe that launches the IDE) to build our projects from the build scripts (or the command line). When specifying the /Build option the IDE is not displayed and everything is written back to the console (or the log file if you specify the /Out option)
See http://msdn.microsoft.com/en-us/library/xee0c8y7(VS.80).aspx for more information
Example:
devenv.exe [solution-file-name] /Build [project-name] /Rebuild "Release|Win32" /Out solution.log
where "Release|Win32" is the configuration as defined in the solution and solution.log is the file that gets the compiler output (which is quite handy when you need to figure out what went wrong in the compile)
We have a program that parses the vcproj files and generates makefile fragments from that. (These include the list of files and the #defines, and there is some limited support for custom build steps.) These fragments are then included by a master makefile which does the usual GNU make stuff.
(This is all for one of the systems we target; its tools have no native support for Visual Studio.)
This didn't require a huge amount of work. A day to set it up, then maybe a day or two in total to beat out some problems that weren't obvious immediately. And it works fairly well: the compiler settings are controlled by the master makefile (no more fiddling with those tiny text boxes), and yet anybody can add new files and defines to the build in the usual way.
That said, the combinatorical problems inherent to Visual Studio's treatment of build configurations remain.
Why would you want to have project that "compiles on Windows that doesn't depend on the VisualStudio project"? You already have a solution file - you can just use it with console build.
I'd advise you to use msbuild with conjunction with makefile, nant or even simple batch file if your build system is not as convoluted as ours...
Is there something I'm missing?
How about this code?
public TRunner CleanOutput()
{
ScriptExecutionEnvironment.LogTaskStarted("Cleaning solution outputs");
solution.ForEachProject(
delegate (VSProjectInfo projectInfo)
{
string projectOutputPath = GetProjectOutputPath(projectInfo.ProjectName);
if (projectOutputPath == null)
return;
projectOutputPath = Path.Combine(projectInfo.ProjectDirectoryPath, projectOutputPath);
DeleteDirectory(projectOutputPath, false);
string projectObjPath = String.Format(
CultureInfo.InvariantCulture,
#"{0}\obj\{1}",
projectInfo.ProjectName,
buildConfiguration);
projectObjPath = Path.Combine(productRootDir, projectObjPath);
DeleteDirectory(projectObjPath, false);
});
ScriptExecutionEnvironment.LogTaskFinished();
return ReturnThisTRunner();
}
public TRunner CompileSolution()
{
ScriptExecutionEnvironment.LogTaskStarted ("Compiling the solution");
ProgramRunner
.AddArgument(MakePathFromRootDir(productId) + ".sln")
.AddArgument("/p:Configuration={0}", buildConfiguration)
.AddArgument("/p:Platform=Any CPU")
.AddArgument("/consoleloggerparameters:NoSummary")
.Run(#"C:\Windows\Microsoft.NET\Framework\v3.5\msbuild.exe");
ScriptExecutionEnvironment.LogTaskFinished ();
return ReturnThisTRunner ();
}
You can find the rest of it here: http://code.google.com/p/projectpilot/source/browse/trunk/Flubu/Builds/BuildRunner.cs
I haven't tried it myself yet, but Microsoft has a Make implementation called NMake which seems to have a Visual Studio integration:
NMake
Creating NMake Projects
Visual Studio since VS2005, uses "msbuild" to define and run builds. When you fiddle with project settings in the Visual Studio designer - let's say you turn XML doc generation on or off, or you add a new dependency, or you add a new project or Assembly reference - Visual Studio will update the .csproj (or .vbproj, etc) file, which is an msbuild file.
Like Java's ant or Nant before it, msbuild uses an XML schema to describe the project and build. It is run from VS when you do a "F6" build, and you can also run it from the command line, without ever opening VS or running devenv.exe.
So, use the VS tool for development and command-line msbuild for automated builds - same build, and same project structure.