I have a VS2012 solution which has 10 projects.The solution is build by a script for all configurations. There is one project out of the ten that I want only to be build only if the solution is built in (debug,release Internal) configuration. How can I do it in VS2012?
Update 1: If we have a solution which has a project which is configured only for debug mode. If we built the solution in release mode, the project builds in debug mode. The point is, I don't want it to build at all if the solution is not currently build under debug/release_internal.
You can set this up using the configuration manager (accessible via the last item in the active solution configuration dropdown):
Then simply uncheck the relevant "Build" checkbox for all the projects you don't want to build in the given solution configuration/platform (don't forget to do this for each applicable combination of solution configurations/platforms):
Related
In our project we now have Code Analysis (CA) set per project and this is propagated to the TFS build server. But we would like not to run CA when we build locally, only on the build server.
The thing is, we have one project (SP 2013) which doesn't produce a DLL and this causes CA errors:
- CA0052 No targets were selected
- Could not load file .... App.dll
We could supress these, but I would like to have CA skip this project on the build server. Is this at all possible?
You could depending on how you do your configurations, only set code analysis to run on 'Release' Configuration. then set the one project so that the 'Release' configuration doesn't run CA. this way your devs can build under 'debug' with No CA and the TFS builds run under 'Release' with AsConfigured
if you are using UpgradeTempalate, you can pass the RunCodeAnalysis=Never as a property to your SolutionToBuld itemgroup. Something like below
RunCodeAnalysis=Never
If you are using default template, you can update it to pass it for the specific solution.
I take it that you want to still run Code Analysis on build outside Team build. If not, the better solution would be to not set the "Enabled Code Analysis on Build" flag.
We are using TFS 2010. In our projects we have multiple configuration files. Each configuration file is needed for a specific build.
Example: Project XYZ includes three configuration files, lets say DEV-CONFING, QA-CONFIG and PROD-CONFIG files.
Now we want to find a way that during the build process, the build process includes the right configuration file and excludes the rest.
Example:
Build for Dev should pickup and copy only the DEV-CONFIG file (and excludes all other configuration files)
Build for QA should pickup and copy only the QA-CONFIG file (and excludes all other configuration files)
Build for production should pickup and copy only the PROD-CONFIG file (and excludes all other configuration files)
Is it possible to change the setting of individual build definition and address this issue?
What is best possible solution for this problem in VS 2010 and TFS 2010?
Please list all required steps and be precise as much as possible because I'm a newbie in TFS 2010 and have not much experience with the whole process.
The "Web Config Transformations in VS2010" addresses the problem of modifying the web.config during compile time. Some people might want the web.config to be modified at deployment time instead of compile time (like me) so that we dont have to recompile the code while moving from one environment to another, in that case you can make use of "Web Deployment Parameters"
You can read more about it at:
http://www.asp.net/mvc/tutorials/deployment/visual-studio-web-deployment/web-config-transformations
web config transformation syntax:
http://msdn.microsoft.com/en-us/library/dd465326.aspx
#user2585405 to your comment above "But all the configurations in my case are for the same mode "Release Mode". The decision should relay on the build definition. So when I use a build definition for DEV, the configuration for DEV should be automatically chosen or for QA build definition, the corresponding QA configuration should be automatically chosen."
Doesnt matter whether currently you have only one configuration. You can add how much ever configurations you want, right click the solution and select the configuration manager. Now add a new configuration say "Dev" (it can be in "Release/Debug" and also select the platform "x86, any cpu etc"). Now add another configuration for QA and PROD. Then come back to your web.config and right click and select "Add web config transformation".
Now you should be able to see the web.Dev.Config, web.QA.config etc. The root web.config will have all the common properties and the DEV/QA/Prod specific config will have only the delta changes (you have to define these entries) which are specific to that configuration (lets say connectionstring). When you compile, within the build definition you can select which configuration you want to compile (Dev, QA, prod) you dont have to keep multiple build defintion. Just one is enough! After the compilation is done, the root web.config will be replaced with the values specific to the configuration for the connectionstring part alone.
Hope this helps!
Yes this possible. You can keep configuration files in different mode for eg:
You can have configuration files in Release mode debug mode, release mode and the common configuration file used by all.
So when you build your solution in Debug mode then the debug mode configuration file will be used and when in release mode then release mode configuration file will be used.
For further clarity take example of web config when you will expand the web config tab you will see the two configuration file in different modes.
Whenever I open a new (web) project in VS 2010 the default build configuration is set to "Active (Debug)". I read somewhere that if I upload my project like this to the server it would have a slight affect on performance (is this true?), so I have to manually go to properties and change it in the build tab to release. Is there any way to tell VS 2010 to open every new project in 'release' configuration?
I believe the build configurations are listed alphabetically, and the first one is always selected when starting a new project.
Since Debug and Release configurations are always added by default, you'll always get Debug selected unfortunately.
You would be better off performing a Publish operation when you want to deploy, as this will not only build in Release (or any configuration you wish), but also will only produce the files that are required by the application. You can publish to a local folder to then upload to a remote server.
Yes, it is true that dll's built in debug mode will not perform as efficiently as dll's built in release mode. A debug mode build includes symbols to allow you to attach a debugger to the dll while it is running. The result of this is slightly larger, less performant set of libraries. However, unless you are doing some really intense mathmatical processing, you probably wouldn't notice the performance loss.
Release mode on the other hand will produce smaller, more efficient dll's but you won't be able to attach an external debugger once you have deployed your application.
I would recommend you leave your applications in debug mode while in development/test, and then before deploying to production, switch to release mode.
UPDATE: I now realize I didn't answer your original question but hopefully you find the advice useful.
This is almost a duplicate of Link build configuration to a publish profile, but that question was not answered...
I have 2 1 Click Publish configurations for my Web Application:
Test Server
Production Server
If I select Build => Configuration Manager => Release and then click the Publish button my application will be published with a release configuration (and visa versa) - without regard to the current Publish profile selected.
But what I REALLY want is...
To set the appropriate Build Configuration from the 1 Click Publish settings. Test Server should be published with my Debug settings and Production Server should be published with the Release settings.
I shouldn't have to make the change from within the Configuration Manager. But I Do.
So, I have 2 questions:
Am I just doing it wrong? Based on a little note in the Publish Settings stating "Use Build Configuration Manager to change configuration" this seems like this is exactly how it is intended to work.
Is there another way of having 2 publish profiles, one with a Debug config and one with a Release config?
The only thing I'm using the debug/release build configurations for is for my Config Transforms that have different connection strings. So, alternative, but still 1 Click, publishing solutions are acceptable. :-)
It's possible to do another way by having multiple Web Deployment Packages.
Basically create two different projects and each one will compile and set the asp.net build config and output. Then script the deployment as part of it.
Bit hacky (wish the publish profiles could set the build config as you wished).
Other than that I normally do via powershell scripts and kick off from my desktop deploy that does all the appropriate compiling and deployment scenarios.
http://msdn.microsoft.com/en-us/magazine/cc163448.aspx
http://johnnycoder.com/blog/2010/01/07/deploy-aspnet-web-applications-with-web-deployment-projects/
I was able to get this to work by installing the Visual Studio Web Publish Update. This update allows you to tie a build configuration to a specific publish profile.
http://msdn.microsoft.com/en-us/library/jj161045.aspx
I want to be able to build a web project and not its dependencies since I know that I have not modified any of the dependencies since the last build. I am looking to cut down the build time if possible. Is there a way to do this?
You could have a solution by
check the setting in Tools >> Options >> Projects and Solutions >>
Build and Run setting : Only build startup projects and dependencies on Run.
OR
If you want to go for sophistication then :
build >> Configuration Manager
from the "Active solution configuration:" dropdown select ""
give a name to your configuration and keep checked the "Create new project configurations" checkbox.
and then choose that config that you want and set the build or not check boxes.
To accomplish this in something I am working on, I created my own solution, added the projects I needed (including the projects I never wanted compiled), and then in the Configuration Manager turned off the check boxes for building the projects I didn't want to build, just as arora described above.
I've also made a copy of an existing solution (that had 16 components in it), saved it under new name (foo.sln -> foo.mine.sln), and then disabled the build of all the other sub-projects except the one(s) I am working on, that way I know for sure that I got the correct build settings.
It's not the simplest solution, but it works well for me, and takes less than 2 minutes to set up and is easy to understand. I normally add the new solution to the version control ignore list so that it never gets checked in.
Rather than project references you can just add the references to the dlls directly (the Add Reference dialog has tabs for these types, choose browse rather than project and remove the other projects from your solution). I typically create a full lib and web project solution for major development. Then just a solution for the website project for fixes where I don't need updated libs/dlls.
Although it is nice to have them autocompile if they have changed during heavy development. If they haven't changed it just refreshes them and recopies them to the bin folder.
Well one way would be to remove project references. Instead stick to dll references. You could use a post build script for dependent projects that copy the updated dll to the web project whenever they change.