I am setting up an automated build for my solution. However, I get errors regarding failures in copying certain information to certain folders. This pertains to build events that each project in my solution has.
What I was wondering is if there was a way to "turn off" the individual build events in the projects, or if there is a parameter to set somewhere that turns these build events off?
The automated build I have set up already does what the individual project build events are supposed to do, and so it is trying to repeat itself and is causing problems. I still need the build events to be associated with the projects because when they're running outside of the development environment, they need to occur for the application to function properly (the build events have to do with dynamically updating information).
Long story short, is there a way to turn off the builds that are associated with each individual project in my solution without actually deleting them? I need them to be there, I just need them to be "invisible" so-to-speak while I'm running the automated builds in the development environment.
I apologize for the verbosity and for the vagueness of everything, it is difficult to explain things sometimes without giving away too much.
EDIT: Not so much an edit as it is additional information for clarity, but nevertheless. The basic goal I am trying to accomplish is to disable the "post builds" that are associated with each of the projects in my solution. I want to keep them, just disable them while I'm running them through the in-house automated builds/tests
After loads of research on the "BuildingInsideVisualStudio" property, and lots of tweaking to get the syntax right, my team and I found what we were looking for.
We inserted the statement
if '$(BuildingInsideVisualStudio)' == 'true' <executed code>
format in the "Post-Build event Command Line" section under the project's properties > Build Events tab.
Some post-build script code like this should work:
if "$(BuildingInsideVisualStudio)"=="" (
#echo TFS build
) else (
#echo Visual Studio build
)
Place your existing code in the appropriate block depending on if you want it to run only in VS builds, or only in TFS builds
You can also change the .csproj file to something like this:
<PropertyGroup Condition=" '$(BuildingInsideVisualStudio)' == 'true' ">
<PostBuildEvent>commands to execute</PostBuildEvent>
</PropertyGroup>
Unfortunately, Visual Studio will not display any information in the Build Events tab, so it might be more difficult for future maintenance.
You could check any of the team build properties and see if they're populated. If so, you can assume it's a team build. I use this approach with our build so that post build deployment labeling etc only occur if it IS running on the build server.
Here's a link with the various team build properties
<SomeTask Condition="$(BuildDefinitionName)!=''">
Related
I have Visual Studio 2010 with Visual Studio 2010 Team Explorer. After I check in code, I can view the changeset number (View History).
I typically put in the Changeset number in the bug log system as soon as I fix something.
Now where/how do I get the build number? Is this a TFS admin thing? Where do I get started? Do I need to use MSBuild instead of using Visual Studio GUI?
Thanks for any help!
When creating a build definition, by default TFS labels each build with this format: $(BuildDefinitionName)_$(Date:yyyyMMdd)$(Rev:.r)
The Default Template's build number can be customized under
[build defintion] > Process > Basic > Build Number Format
However, you may want to check out Versioned TFS 2010 Build for more control over the build number format and automatic versioning of the assemblies (via AssemblyInfo.cs).
through gui:
right click on builds > view builds > tab to "completed"
build definition > all
quality filter > all
date filter > today
double click on the build of interest:
you should see the build number and changeset at the very top.
=========
When you commit you should use the dialog to associate your commit to a work item - this way you don't have to manually set any of this.
To get these details in msbuild the data can be retrieved using:
<Exec Condition=" '$(IsInTeamBuild)'=='True'" Command=""$(TfsTask)" history ../ /r /noprompt /stopafter:1 /version:W > "$(TemporaryFolder)\grab-changeset.txt"" />
<Exec Condition=" '$(IsInTeamBuild)'=='True'" Command=""$(TfsTask)" properties "$(MyMSBuildStartupDirectory)\all-companies-run-after-update.js" > "$(TemporaryFolder)\grab-properties.txt"" />
we use the above to extract: build#, branch, revision#
It seems that you haven't set up a TFS-build at all.Even though this will require some time to grasp as a concept & tailor a solution to your own needs, this is definitely worth the investment (or, the other way around, NOT using TFS build makes the whole investment into TFS a lot less worth it).This might be a nice starting point, there are a lot of useful resources out there, I 'd advise you to take a deep breath and dive right in. You can always return with more specific questions.
Let's pretend that we have the following servers [dev, test, production] and that dev and test are very similar in configuration while production is quite different.
If I'm using web.config transforms that means I have to duplicate a lot of settings för Web.dev.config and Web.test.config. It would be very nice if I could use the same transform mechanism for my transforms so that test.config is based on dev.config.
I have thought of two possible approaches, i'm not sure any of them would work:
Try to get MSBuild to first transform dev.config and then run test.config against the result when we are running under test configuration
trying to get the transform mechanism to work for transformations files. I would somehow run test.config against dev.config and create a temporary file which I then use as as a transformation against Web.config.
Does anyone know if something like this is possible? And if so how would one go about to set it up?
The TransformXml is just an MSBUILD task that is invoked post compile. If you extend/mod your build you can have it run the transform task twice, or allow the normal run against your configurations, then provide a second file and use the task to perform that.
If you are familiar with msbuild, this is pretty simple. If not, reply/comment, and I'll try to provide examples later today.
But in the end, yes its possible, as I've had similar need on past projects.
I have even more configurations. And all of them synced with T4. See my answer here.
Although this has been answered I wanted to update it with an answer reflecting changes made in Visual Studio 2012 that make this considerably easier.
As of Visual Studio 2012 it is possible to "chain" build and publish profile transforms.
As such you can have a "Release" build transform that takes care of common configuration such as switching off debugging, switching on custom errors, and any number of "Publish" transforms which are associated with a publish profile, adding instance specific data such as connection strings and appSettings.
In VS 2012 (as well as the publishing updates for VS2010 through the
Azure SDK) now support the concept of publish specific transforms. You
can also now specify the project configuration used for a profile when
publishing on the publish dialog...
In this case I have created a profile named Production and set the
Configuration to Release. When I publish this project the following
transformations will be applied (if the files exist) in this order.
1.web.release.config
2.web.production.config
See Profile specific web.config transforms and transform preview for more information.
Do I have some weird setting that is making this happen? I only want to change the text of a message box (and no other assemblies depend on that one) yet VS rebuilds all of my projects and it takes forever. Any ideas?
You can find out what is causing Visual Studio to think each project is out of date, and then address the issue directly.
Select Tools → Options → Projects and Solutions → Build and Run.
For the setting "MSBuild project build output verbosity:" select "Diagnostic".
Build.
You will get a huge amount of output in the output window detailing exactly what the build is doing. Before building each project it will print out why it thinks it is out of date. An example of such output is:
Project 'Foo' is not up to date. Input file 'c:\Bar.cs' is modified after output file
These "not up to date" messages should point you to the real cause of the unnecessary builds, which you can then fix.
There's some limited control over this without using Configurations if you check the option to only build startup projects and dependencies on Run.
Tools → Options → Projects and Solutions → Build and Run → Only build startup projects and dependencies on Run
You can exclude projects from your general build through the build menu..
Build → Configuration Manager → Uncheck projects that you don't want to always build.
This can massively speed up build time by only building projects that absolutely need to be built every time.
Note though you will have to build the projects that you've unselected independently (right click->Build on the project etc) if they need to be rebuilt.
You can also setup alternate build configurations so you can mix and match what will build when.
The play button is the start debugging feature.
Yes, Visual Studio will ask every project in the solution to build at that point. But note asking to build and actually building are different things. Asking to build merely says, about to do something build again if you would like. MsBuild will then do a bit of checking under the hood and decide if it should actually build the underlying project.
If your project is actually building then there may be some other problem going on. Can you give us some more info like language, project type, etc ...
It's also possible to change the setting 'On Run, when projects are out of date' to 'Never Build' instead of 'Ask'.
(its in the menu 'Tools -> Options -> Projects & Solutions -> Build & Run)
This way, you'd need to press F6 every time you make a change to build the out-of-date projects, but at least it will allow you to debug with F5 without the recompile.
I have to say this is not ideal, but it's something.
There was one issue though I had while using casini: The app-pool didn't recyle every time I press F5 because casini keeps running. You will have to manually stop casini from the icontray when you encouter problems but it's a major time-saver in contrast to rebuilding the entire site.
The "Play" button is probably not what you think it is, or you have incremental linking and the like turned off in your Project Settings.
In Visual Studio, I have custom MSBuild actions for various tiers - development, staging, testing, and so on. These scripts will automatically compile everything, do web.config swapping, and push code out to a location based on the chosen configuration. Usually when I want to run one of these builds on something other than development, I call the build script from the command line.
Though I try to be as diligent as possible, sometimes myself (and others working in the solution) will accidentally leave the configuration in one they didn't mean to - maybe they switched it to the "staging" configuration to view how the code looks with its specific preprocessor directives. Then they hit "F5" thinking they're in development to debug...and push busted code out accidentally.
So the question is, is there a way to still have the build scripts tied to the configuration, but disallow builds for certain configs from the IDE? Or pop up a warning? Or am I going about this the wrong way to begin with?
To have the staging build fail unless it's a Team Build, you should be able to use
<Error
Text="No Staging builds except on the Team Build server"
Condition=" '$(IsDesktopBuild)'=='true' And $(Configuration)='Staging' " />
CruiseControl.NET also passes distinctive properties to msbuild, so a similar idea would work with one of those in place of IsDesktopBuild.
I'm not aware of any differences in the default properties between a Visual Studio build and a command line msbuild one, but if you can bear a little extra typing, this should do the job
<Error
Text="You didn't say the magic word"
Condition=" '$(MagicWord)'!='please' And $(Configuration)='Staging' " />
then
msbuild /p:Configuration=Staging /p:MagicWord=please
Visual Studio won't include the extra property, so the build will fail.
Task Class for adding more control on MSBuild compile process.
I have a solution with several projects, where the startup project has a post-build event that does all the copying of "plugin" projects and other organizing tasks. After upgrading the solution from VS 2005 to VS 2008, it appears as though the post-build event only fires if I modify the startup project, which means my updated plugins don't get plugged in to the current debugging session. This makes sense, but it seems like a change in behavior. Is anyone else noticing a change in behavior with regard to which projects get built?
Does anyone know of a workaround that I can use to force the startup project to rebuild whenever I hit F5? Perhaps I configured VS 2005 to work this way so long ago that I've forgotten all about it ...
I think you need to reorganize the responsibilities. Each component should be responsible for itself and therefore copy its generated goodness where it needs to go. That way it doesn't matter if/who/what/when/where got built. Whatever is updated will put itself into the proper place.
IMO the other suggestions are no-nos since they'll circumvent the compiler's smarts to know when a rebuild is necessary for the main project. And hence killing any compile time-savings. If your "plugin" projects are assemblies (and not just project-references from the main project), then you do not need to rebuild the main project each time a plugin is rebuilt. The new assembly will get selected into the process / debugger w/o the main project needing a rebuild.
Why not just add a dependency to the "startup" project for each of the plugins? This will force the project to be rebuilt if any of the others change, and you won't have to mess with any other pre/post-build events.
I don't know if this is the right way to do it but you could add a prebuild event to your startup projcet (if it's static) to clean the project which will force a rebuild.
something like:
devenv project.csproj /clean
This is a pain. What we really need is for Microsoft to allow us to hook into a Post-Solution Build event. You can do this via macros but that's too complicated.
I'm assuming this is a C++ project because I don't have this problem with C#.
This is my solution, it's not elegant but it works:
Create a new project whose only purpose is to run the post-build script. Mark it as dependent on every other project in the solution.
Add a dummy file to that project called dummy.h or whatever.
Right click on dummy.h in Solution Explorer and select Properties.
Select 'Custom Build Step'.
For the command line type 'echo' and for Outputs just type 'dummy' or something else that will never exist.
This project, and therefore the post-build script, will now be run on every build.
John.
flipdoubt: they are projects created originally in 2008. My suggestion if it's not working C# is to look in the Build Events tab and check the setting of the "Run the post-build event:" drop down. If it is set to 'When the build updates the project output' this might be your problem, try setting to 'On successful build'.
John.
I'm having the same issue here and it is VERY annoying. John Richardson is right in that there should be a Post-Solution Build event (and a Pre-Solution Build event) that applies whenever ANY project in the solution is being built.
I don't think there is any good workaround to get this outcome in the current VS 2008 IDE.
Starting from #lomaxx suggestion, I got a very similar setup working by adding the following line at the end of the post-build event of the startup project:
"$(DevEnvDir)devenv.exe" "$(ProjectPath)" /clean
Note that this makes the startup project build the next time you need to debug, so you should make sure the project gets built at least once.
PS. I initially tried the pre-build as suggested, but that didn't work (and I think it makes sense - if VS thinks a project doesn't need building, it won't execute any events for that project).