I read quit a few Stackoverflow Questions about building mergemodules via commandline but all of them were accepted when either somebody suggested to use devenv for compilation or use Dark to create wix-files from existing msi files.
Considering the following:
VisualStudio isn't installed on the buildserver I have to use.
I am using nant + msbuild to compile the solutions
I would like to compile mergemodules from .vdproj (because Visual Studio detects dependencies automatically)
and create a msi setup from multiple mergemodules
... how can I build the merge modules from commandline without devenv and without loosing the comfort of automated dependencie resolving for mergemodules in visualstudio?
Maybe there is a nanttask for it I haven't found?
MSBuild doesn't support Visual Studio deployment projects, my advice would be to bite the bullet and go with Wix.
Perhaps VS2010 will use MSBuild schema for vdproj files? I'm guessing no, but couldn't find any links.
currently, it is not possible to do this with msbuild. but i am pretty sure you might be interested in this MSDN blog article because of your question related to merge module/setup projects in vs. It seems they won't continue to support .vdproj files in upcomming versions of visual studio (2010 will be the last supporting them).
So you may run into problems in the future even if you're using devenv instead of msbuild.
... but this article could be some kind of whispering, too. Anyway, there are a lot of alternatives on the road if you want to build setups.
Even I was facing the same issue. Use below format
call "C:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\vcvarsall.bat"
cd /d Path_to_sln
"C:\Program Files (x86)\Microsoft Visual Studio
10.0\Common7\IDE\devenv.com" "Required_path\solution.sln" /Project "Required_path\Setup\Setup.vdproj" /Build Release /Out
"Required_Path\vs_errors.txt"
I would be pretty surprised if you are able to build .vdproj files without installing Visual Studio.
Related
I'm trying to automate obfuscation by using post-build commands in Visual Studio 2015. I've followed the steps from this article on MSDN.
I've added the post-build command as mentioned in steps and created Dotfuscator.xml, placed in root directory i.e. where vbproj file is located.
Once I build the project I get following error message.
Here is the post-build command:
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\PreEmptive Solutions\Dotfuscator and Analytics Community Edition\dotfuscator.exe" /q /p=SourceDirectory=$(TargetDir),SourceFile=$(TargetFileName) $(ProjectDir)Dotfuscator.xml
Any hint or solution will be appreciated.
You need to quote those paths you are passing...
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\PreEmptive Solutions\Dotfuscator and Analytics Community Edition\dotfuscator.exe" /q /p=SourceDirectory="$(TargetDir)",SourceFile="$(TargetFileName)" $(ProjectDir)Dotfuscator.xml
Or Perhaps
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\PreEmptive Solutions\Dotfuscator and Analytics Community Edition\dotfuscator.exe" /q /p="SourceDirectory=$(TargetDir),SourceFile=$(TargetFileName)" $(ProjectDir)Dotfuscator.xml
Test it by running the exe from the command prompt to see how the thing handles that argument.
Now that you've sorted out the quoting issue as Trevor described, I think the next issue is that you're probably running a version of Dotfuscator that doesn't have command-line support.
Visual Studio 2015 Update 3 (and VS 2017) includes a version of Dotfuscator Community Edition (CE) that has command-line support. (You have to register to enable it.) If you're using an earlier version of VS 2015, you can download a version of Dotfuscator CE that has command-line support from PreEmptive; see the instructions here for details.
Full disclosure: I work for PreEmptive Solutions.
With the help of answers from #Trevor and #Nathan, here I'm able to achieve what was desired.
First I created the Dotfuscator.xml file using Dotfuscator.exe. Providing input files and generated obfuscated DLL once.
Once it's confirmed that the XML file working fine, I then added following post build event build command
dotfuscatorCLI.exe "$(ProjectDir)Dotfuscator.xml"
Another way to achieve same results
Above solution will work but it would be specific to one computer. So if you are working in a team and there are chances that you build your solution on multiple machines then I would prefer the approach defined in the article whose link was shared in my Question. However that approach requires a minor tweak.
Here is the post build command that will work:
dotfuscatorcli.exe /q
/p=SourceDirectory="$(TargetDir)\",SourceFile=$(TargetFileName)
"$(ProjectDir)Dotfuscator.xml"
Please note here the Dotfuscator.xml is the one that is referred in the MSDN article, not the one generated by dotfuscator.exe as mentioned in previous solution. Also note, if your TargetFileName contains spaces then put double quotes around it.
Hope this would help others.
We want to create an .MSI package from a web deployment project in Visual Studio 2008.
Now we want to use continuous integration and we would need the .MSI package build in the nightly builds.
Till now we used standard Visual Studio Web Setup project, but this is not compatible with the MSBuild. So we decided to use WiX.
The problem is that I have not found any good tutorial/documentation about this.
Is there a way to do a WiX installer package from a web deployment project? If yes, how?
Also, I tried to use heat.exe to create the XML for the WiX project .wxs file, but it seems that heat.exe doesn't recognize the web deployment project format.
Thank you for your responses.
Regards,
V.
I wrote a blog post about this recently - http://www.chrissurfleet.co.uk/post/2011/07/01/Using-Packaged-Project-Output-in-WiX-and-Visual-Studio.aspx
In short, its fairly easy to use msbuild to package up your web app and then pass it to heat to generate your installer from.
Hope this helps.
You've probably long since found a solution for this, but to elaborate on Tom Cabanski's answer, you can invoke Visual Studio to build the msi on the command line using "devenv.com" via an external process from within your build. It's not a pretty as using msbuild, but it gets the job done. Below is an example of how to invoke Visual Studio:
"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\devenv.com" your.sln /build Release
Where your.sln is the solution file for the solution you wish to build, and Release is the configuration you wish to build, ensuring that the configuration you choose actually builds the vdproj project.
Following the successful execution, you can grab the msi from the appropriate configuration's bin, and do what you want with it.
I'd appreciate your response to this with your findings/approach, as I'm trying to decide whether to adopt WiX or InstallShield as the approach to building msi's for Web Applications within TFS Build, or to continue with the approach I just described. I haven't had to opportunity to try WiX out, and my very limited exposure to InstallShield suggests that this is far to involved for my need, which is to produce a simple deployment aid for some relatively straight-forward web applications to the company intranet via TFS Build.
We used WIX on the installers for our last couple of projects and ended up regretting it. I would stick with the VS built-in projects and just invoke the VS IDE from the command line in the CI build.
I have a Visual Studio solution file (.sln), with several projects (VB.NET and C#, .vbproj, and .csproj files, respectively), and I have a Windows application, and I use ClickOnce to publish it.
Now, I need automate the Publish option using MSBuild or another good solution (cmd, VBScript, or BAT scripts).
How can I do it?
Well, ClickOnce uses MSBuild to publish itself. Therefore I would recomment to use MSBuild for your build-automation. See the reference on MSDN.
The first step is easy. You just run MSBUild with 'Publish'-target from the console. The settings made in Visual Studio are applied.
However, there are some tricky bits. For example, when you run it from the command line, the version number isn't increased. In my project I've solved this by passing the version-number from the build script.
Another tricky-part is when you want to run the build script on your build-server without Visual Studio installed. There you might have to copy some to make it work.
Background:
I always try to ensure the following tenet in my projects:
After a fresh checkout a developer should be able to do all project related tasks with solely the contents of the combined folders.
Obviously, this isn't always possible (e.g. Visual Studio for Windows development). However, I really dislike having to install any third-party libraries or tools that are specific a project like log4net, NHibernate, NUnit, etc. There are number of reasons for this including:
For a given development machine, you may work on several different projects, all which leverage different versions of the same third-party library or tool.
Minimizing the environment setup requirements makes setting up new developers or machines much easier
Facilitates easier maintenance of automated builds
Assumptions/Contraints
I am currently using WiX 3 beta, but if there is way for either 2.0 or 3.0 please respond
I am using Visual Studio 2005
The IDE syntax highlighting is not a requirement.
Question:
Is it possible to avoid local installation of the WiX toolset and use flat files instead? If so, please explain how.
See Also:
First, build your WiX installer:
Create a new WiX Installer Project in Visual Studio 2005.
Build your WiX XML accordingly.
Now, to integrate the WiX toolkit into your source tree:
Copy c:\Program Files\Windows Installer XML v3\bin to a sub-directory in your source tree. I used WiX\bin relative to my .wixproj file.
Copy c:\Program Files\MSBuild\WiX\v3.0\ to a subdirectory in your source tree. I used WiX\v3.0 relative to my .wixproj file.
Either add the following code or replace the line that follows:
<WixTargetsPath Condition=" '$(WixTargetsPath)' == ''>$(MSBuildExtensionsPath)\Microsoft\WiX\v3.0\Wix.targets</WixTargetsPath>
With the following lines:
<WixToolPath>$(MSBuildProjectDirectory)\WiX\bin\</WixToolPath>
<WixTasksPath>$(MSBuildProjectDirectory)\WiX\v3.0\WixTasks.dll</WixTasksPath>
<WixTargetsPath>$(MSBuildProjectDirectory)\WiX\v3.0\Wix.targets</WixTargetsPath>
As you can see, the WixToolPath, WixTasksPath and WixTargetsPath directives reflect the location of the folders I've instructed you to copy.
Rename your .wixproj to .csproj. This ensures that Visual Studio does not get confused by the .wixproj file but because the .wixproj is a valid MSBuild project, Visual Studio will be able to work with it.
Using this method, the WiX directory as described is about 9MB large.
I know with WiX 2, you can just download the executable files and the dll's to whatever directory your project is in. Then you create a .bat file to run candle.exe and light.exe with the parameters you need to build your installer.
That way, all your projects can have their own version of WiX with a disk drive hit of only about 4 megs each.
I'm not positive, but I think you can do the same with WiX 3.
Is it possible to build Visual Studio solutions without having to fire up MonoDevelop?
Current status (Mono 2.10, 2011): xbuild is now able to build all versions of Visual Studio / MSBuild projects, including .sln files. Simply run xbuild just as you would execute msbuild on Microsoft .Net Framework. You don't need Monodevelop installed, xbuild comes with the standard Mono installation.
If your build uses custom tasks, they should still work if they don't depend on Windows executables (such as rmdir or xcopy).
When you are editing project files, use standard Windows path syntax - they will be converted by xbuild, if necessary. One important caveat to this rule is case sensitivity - don't mix different casings of the same file name. If you have a project that does this, you can enable compatibility mode by invoking MONO_IOMAP=case xbuild foo.sln (or try MONO_IOMAP=all). Mono has a page describing more advanced MSBuild project porting techniques.
Mono 2.0 answer (2008): xbuild is not yet complete (it works quite well with VS2005 .csproj files, has problems with VS2008 .csproj and does not handle .sln). Mono 2.1 plans to merge the code base of mdtool (MonoDevelop command line build engine) into it, but currently mdtool is a better choice. mdtool build -f:project.sln or man mdtool if you have MonoDevelop installed.
for now as per August 2017 we can use
msbuild
command as xbuild is depreciated.
xbuild now supports solutions and projects, both VS2005 and VS2008.
I think you are looking for xbuild:
http://www.mono-project.com/Microsoft.Build