Is there a way to temporarily disable pre and post build events?
i.e. build without build events (which are taking a bit of time but arent always crucial to run)
At the moment, I have minification and a couple of other things going on and I don't always need that.
The simplest way to disable the build events is passing empty values:
msbuild your.sln /p:PreBuildEvent=;PostBuildEvent=
Stuff like minimization only matters for the Release build. So you could skip it like this:
if "$(ConfigurationName)" == "Debug" goto skip
; stuff here...
:skip
There are some other macros you can use, click the Edit button and the Macro>> button to see them. Environment variables can be tested as well, use %varname%. But are much harder to set.
I also played a little with msbuild foo.vcxproj /p:PreBuildEvent= /p:PostBuildEvent=, but for me it didn't work, probably because I am using custom props files.
What I found to work however was /p:PostBuildEventUseInBuild=false
Check your post build event settings. On the "Build Events" tab change the "Run the post-build event" combo box value to "When the build updates project output". Post build events will be executed only when output assembly is updated.
OR
Use MSBuild command to build your solution (this is useful for multi-solution projects).
Create "DisableBuildEvents.msbuild" file somehere on your PC.
DisableBuildEvents.msbuild content:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="PostBuildEvent"/>
<Target Name="PreBuildEvent" />
</Project>
Execute MsBuild with CustomAfterMicrosoftCommonTargets property set in the command line:
MSBuild.exe YourSolution.sln /t:Build p:CustomAfterMicrosoftCommonTargets="c:\DisableBuildEvents.msbuild"
Note: CustomAfterMicrosoftCommonTargets value should be full path name.
Related
I have a solution in Visual Studio in which I have a shared property sheet which contains a Post-Build Event command (bar) which needs to execute for every project.
Foo.props > Common Properties > Build Events > Post-Build Event >
Command Line = bar
How do I then specify additional project-specific Post-Build Events? The usual "Inherit from parent or project defaults" is missing, and I would rather not have to manually add bar to every single project as it makes it hard to maintain.
After finding this solution and looking at the other post. I found it impossible to understand why the VC++ team would leave this feature out.
After looking through the Macros for the property pages you can include the command from the previous properties using the %(Command) macro / environment variable. This works for all build events.
PropertySheet1.props
copy some.dll $(OutputPath)
%(Command)
PropertySheet2.props
copy other.dll $(OutputPath)
%(Command)
Results in all commands being executed.
Based on this post, it doesn't seem possible. You posted your question a while ago; did you manage to find a feasible alternative?
Edited after feedback:
A potentially messy alternative would be to define your command as a macro:
<!-- CommandX.props -->
<PropertyGroup>
<CommandX>bar</CommandX>
</PropertyGroup>
Then you could add $(CommandX) to the post-build command of the project or to another property sheet. If $(CommandX) doesn't exist, it is quietly ignored.
If you add this macro to another property sheet, then you'd have to Import your CommandX property sheet so that $(CommandX) inherits a value:
<!-- Some-Other-Property-Sheet.props -->
<ImportGroup Label="PropertySheets">
<Import Project="CommandX.props" />
</ImportGroup>
After learning a bit more about the build process, I'd like to recommend using MSBuild tasks; in particular, the Exec task might offer the most feasible solution.
As some Post-Build Events did non inherit from the property sheet they are defined in, I questioned the duck and landed here.
I have good news:
Since Visual Studio 2013, the Pre-Build and Post-Build event command lines have a "Inherit from parent or project defaults" option, which adds all events from the property sheets.
(Tested with Visual Studio 2013 and 2017 Professional)
In Visual Studio, we're using the click-to-publish thingy... is it possible to write a plugin or somehow give a confirmation dialog when you click publish to make sure that's what you want to do? don't want people accidentally overwriting production
I don't know is it possible to turn this on by default, but if not - at first you need to understand how VS does this. Probably this is some msbuild targets file (msbuild task) which has some settings like "Publish = True/False". So what you can do - is to create a new msbuild task which you will invoke before the Publish task (you can try to add this task to your project file). In your task you will check if "Publish = True" - you will show message box "Do you want to publish?" and if somebody will click No, you just need to override "Publish" value in msbuild to False. I think this should work.
I don't know of any plugin which can do this.
One approach to mitigate the risks would be to create multiple configurations combined with multiple publish profiles:
E.g.
configurations: Debug_Development, Release_Development,
Release_Production where, using web.config transforms, set
different settings for connection strings, app settings, etc. (a nice
introduction to web.config transforms, and not only, can be found
here)
publish profiles: debug_development, release_development and release_production, each of them with different ftp settings (if you deploy via ftp) and each of them connected to the corresponding configuration
We're using the Sql Server 2012 SSDT which removed the deploy option in Visual Studio for the database projects (now sql projects). We'd like to automate the Publish step as we had for deploy, but it's not clear how to do this. so thA couple of questions:
I've added the .publish.xml to the project (after the first manual publish, checking add to project). Even after that, and setting it to the default, when I double click it, it builds, but always pops up settings window, where I need to click the "Publish" button to continue. Is there a setting that would skip this prompt and use the current values?
It seems that each publish generates a version of the sql output. How can I suppress this- i.e. overwrite the base file each time?
And lastly, any pointers for updating the build to use the new project type and publish command for the automated builds would be appreciated.
How to restore the Deploy option: (Visual Studio 2010/2012 only -- this is no longer supported in Visual Studio 2013)
The Deploy option is still present but for some reason it's not available in the menus. (Cursed Visual Studio team!) I've worked around this by adding the Deploy option to one of the toolbars as follows:
Click the arrow on the right-hand side of a toolbar.
Click "Add or Remove Buttons", then Customize.
In the Customize dialog click Add Command.
Select the "Build" category, then select the "Deploy Selection" command.
After saving your selection the "Deploy [project name]" option will appear on the toolbar. You'll need to select your project in Solution Explorer for the button to become enabled.
Note that the deployment settings are different than the publish settings. The deployment settings are configured in the project's properties on the Debug tab.
To answer your questions about the Publish option:
1) How to use a specific publish file by default and avoid the annoying prompt
I don't think there's a way around this.
2) How to publish the entire database, not just the changes
Open your .publish.xml file in a text editor and add <AlwaysCreateNewDatabase>true</AlwaysCreateNewDatabase>.
For example:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<TargetDatabaseName>MyDatabase</TargetDatabaseName>
<DeployScriptFileName>MyDatabaseProject.sql</DeployScriptFileName>
<TargetConnectionString>Data Source=localhost\SQL2012;Integrated Security=True;Pooling=False</TargetConnectionString>
<PublishDependentProjects>False</PublishDependentProjects>
<ProfileVersionNumber>1</ProfileVersionNumber>
<AlwaysCreateNewDatabase>true</AlwaysCreateNewDatabase>
</PropertyGroup>
</Project>
3) Command-line syntax for automated builds
First build your project with msbuild as you normally would so that the .dacpac file is created in the bin.
Then use sqlpackage.exe to publish using your .publish.xml file:
C:\Program Files\Microsoft Visual Studio 10.0\Microsoft SQL Server Data Tools\sqlpackage.exe /Action:Publish /SourceFile:C:\[path to my project]\bin\Debug\MyDatabaseProject.dacpac /Profile:C:\[path to my project]\MyDatabaseProject.publish.xml
Note that the path to sqlpackage.exe may be different.
A bit late to the party, I admit, but maybe this will help others who stumble across this discussion. My company is presently moving to VS2012 and we have all three of the same issues as Keith. I have found workarounds for #1 and #2.
For #1, I use AutoHotKey to monitor for the existence of the publish window, and automatically click the "Create Script" button. You could of course have the script automatically click the "Publish" button instead. In this example if the publish profile is not "XYZ" (I always prefer manual intervention for production server deployments) then go ahead and send an Alt+G to generate the script.
#Persistent
SetTimer, ClosePopups, 5000
return
ClosePopups:
if WinExist("Publish Database ")
{
WinActivate, Publish Database
WinGetTitle, TitleText, A
If not TitleText = "Publish Database XYZ.publish.xml" {
Send, !G
}
}
return
For #2, every time we publish it increments the filename with a number suffix and we end up with lots of files in our deployment folder. I just used pre-build events to clear out the .sql and .txt files before the build:
if exist "$(ProjectDir)$(OutputPath)*.publish.sql" del $(ProjectDir)$(OutputPath)*.publish.sql
if exist "$(ProjectDir)$(OutputPath)*.txt" del $(ProjectDir)$(OutputPath)*.txt
The best way I have found to automate the deployment of SSDT database projects is to use msbuild. Originally we were using VSTSDB and used msbuild against the *.dbproj file. As it turned out the arguments for deploying sqlproj files is exactly the same.
Because the old argument list works for us, I didnt swap to using the public.xml file style. There quite a bit of documentation for the vsdbcmd.exe and msbuild against dbproj. I would use that as reference.
Here's argument list, and execution output as we define it for FinalBuilder execution
[ MSBuild Project [ C:\xx\xxx\xx\xx\MyProject.sqlproj ] ]
Configuration : Release
OutDir : C:\Builds\1\xxxxx\builddefname\Binaries\Release\
DeployToDatabase : True
TargetDatabase : ExistingDatabaseName
TargetConnectionString : Data source=.;Integrated Security=SSPI;**
Build started 3/23/2012 2:17:08 PM.
Deployment script generated to:
C:\Builds\1\xxxx\builddefname_FB\Binaries\Release\MyProject.sql
Dropping FK_at_lusys_assetCategory_at_lusys_image...
Creating FK_dcb28374eeabe8e715038984419...
Creating FK_d82897e4acd966d4b136c242cef...
Checking existing data against newly created constraints
Update complete.
Done Building Project "C:\xxx\xxxxxxx\xxxxxxxxx\MyProject.sqlproj" (Deploy target(s)).
Build succeeded.
0 Warning(s)
0 Error(s)
and putting together the msbuild command line looks like this:
msbuild XXX.sqlproj /target:Deploy /p:Configuration=xxx;OutDir=xxx;DeployToDatabase=True;TargetDatabase=xxxx;TargetConnectionString="xxxxx";AlwaysCreateNewDatabase=True
Usually, visual studio puts output files to bin/debug or bin/release.
When solution contains a large number of projects its not easy to modify each project output manually.
Also edits in csproj files no desirable, because some of them is shared between solutions..
My questions: Is anybody knows a tool, which can quickly configure output path ?
UPDATE: my problem solved by TFS Build
Presumably you have at least one project in each solution that is unique to that solution. In the Post-Build event of that, copy the contents of each project's output to the required location.
We often to this using a batch file. It's crude but effective. In our project that's unique to the solution we create a Release.bat file. This contains a number of file copies to copy all of the required components from the various output directories of the other projects. You can then just run the batch file in the post build event. We usually copy everything to a "Latest Release" fodler when the solution is built. If this becomes a proper release we will rename the Latest Release folder to the actual release number.
If you have multiple build configurations, or even just use the Debug and Release configurations, you can use an If statement in the Post-Build event to decide which batch file to run. So you could create a Debug.bat, Release.bat etc which do what you need. It can be tedious to set them up and get them working correctly at first, but they are very useful once fully implemented.
Customize your project using the msbuild properties which you can do if you follow these steps:
Go to the solution explorer and unload one project by right clicking on it and select Unload Project.
Then right click again on the unloaded project and select Edit Project. This will open the XML definition of your project, and you will have intellisense for the layout which will help you perform the next steps.
In the visual studio editor find the first PropertyGroup tag and add these lines near or at the end of the closing PropertyGroup tag:
<SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">..\</SolutionDir>
<BuildDirectory Condition="$(BuildDirectory) =='' or $(BuildDirectory) == '*Undefined*'">$(SolutionDir)\build\</BuildDirectory>
The above SolutionDir is defined in msbuild properties which you can obtain using this answer: msbuild script using solution information and also check out the well known msbuild properties here
The next step is to find the OutputPath tag for each configuration and edit it like this:
<OutputPath>$(BuildDirectory)\x86\AutomatedDebug\</OutputPath>
The example above assumes you have a configuration named AutomatedDebug with destination platform x86.
The output will be
x:\projects\whereever-your-solution-is\build\x86\AutomatedDebug\
Repeat for each project.
To unload more than one project, collapse all projects in the solution explorer and shift click or ctrl click to select all or some projects, then right click on the selected group to unload, unfortunately you cannot do this for editing, at least in visual studio 2010.
I am the first to admit that this is somewhat cumbersome to do for existing projects, but you could easily create a visual studio project template that has these settings changed so that new projects will use a more convenient default output directory.
You cannot edit the output directory directly in visual studio because the project properties editor escapes any $() enclosed text.
Also you could only modify the OutputPath using the name of a system environment variable enclosed in $(). This last option is to enable a global output directory.
If you build any single project modified in this way using msbuild directly in the commandline the output directory will be created one directory above from where you ran msbuild
..\build\x86\AutomatedDebug
If you are in a team, you should warn them not to edit the output directory directly by hand, as this action will overwrite any customization.
Hope this info is useful.
Greetings.
I'm using Visual Studio 2008 and would like to create a sort of container project that holds a number of DLL's that must be installed with a solution. I want them to be in a separate project so that they can be easily attached to a solution as a group.
I created an empty project call TEST, added my DLL's to it with a Build Action of "Content", and set them to "Copy Always". That all works exactly as I want. The problem is that if I set the TEST project Output Type to "Console Application" or "Windows Application" that it won't build because there's no entry point. If I set the Output Type to "Class Library", it builds but I end up with an extra TEST.DLL file that I don't really want.
Is there anyway to sort of set the Output Type to "none"? I want the build actions to take place (so my DLL's get copied) but I don't want the dummy class assembly created. Any ideas?
Thanks!
Assumptions for the following step-by-step guide:
Let's assume that you have a solution with two projects:
Main: your main (start-up) project.
BundledDLLs: a library project which contains the .dlls that should end up in the main project's output directory.
Step-by-step guide:
The easiest way to achieve your goal inside Visual Studio is probably the following:
Add all .dlls to BundledDLLs and set their Copy to output directory to Copy if newer.
This is done in the Project Explorer and the Properties windows.
Configure BundledDLLs's output directory to be identical to Main's output directory.
This can be done in the Build tab of BundledDLL's Project Properties page. Enter something like the following in the Output Path textbox:
..\Main\bin\Debug
Set up BundledDLLs as a dependency of Main.
Do not add BundledDLLs as a project reference to Main, as you usually might; instead, use the Project Dependencies dialog to . This will tell the build tool that whenever Main is built, BundledDLLs needs to be built first.
Do this by right-clicking on the Main project node to open the context menu; select Project dependencies... from there. In the now opened dialog, first select Main from the drop-down list; then check BundledDLLs in the project list below. BundledDLLs is now registered as a dependency of Main.
P.S.: One disadvantage of not having an explicit assembly reference in Main is that some tooling might not recognise the dependency. For example, ClickOnce deployment might not work properly.
Add a post-build event to BundledDLLs that deletes the superfluous BundledDLLs.dll.
As you said, you don't want, and don't need, the dummy output generated when BundledDLLs is built. So add a post-build event that simply deletes this .dll once it's been created.
Open the Build events tab in BundledDLLs's Project Properties page, and enter something like the following in the post-build textbox:
DEL "$(TargetDir)\$(TargetName).*"
(In case you wondered: The reason why you didn't add this project as a project reference to Main earlier is because if you had done so, Main would be looking for BundledDLLs.dll, which it wouldn't be able to find since you don't actually want such a file to be generated.)
P.S.: One disadvantage of adding such a post-build step is that it might interfere with incremental builds. If your project keeps getting recompiled from scratch after this, you might be better off removing the post-build step and living with the extra BundledDLLs.dll in your solution's output directory.
Another option is to use a makefile project, which doesn't require you to build/link anything.
In your project properties (right click property in solution explorer and click "Properties"), under "Configuration Properties" and then under "General", choose "Makefile" from the "Configuration Type" drop-down menu. The build output will include the warning "The property 'NMakeBuildCommandLine' doesn't exist...Skipping" but the build will succeed without building any dll/exe/etc.
While other answers here may better address your specific need, specifying a makefile more directly answers the question title "Possible to create Visual Studio project with Output Type of none?" I hope this is useful for people who google something to that effect and land here.
Credit goes to Xeek in the #winapi freenode irc channel for sharing this tip.
Instead of putting them in a project, you can put the files in a Solution Folder. One of your projects can have a build action that does the copying, but since they won't be in a project, they won't try to "build".