Develop Reference

(Wix installer) how to include custom action dependency

I got 3 projects in Install solution:
Custom Action dll written in c#
Custom Action dll written in c++
Util dll written in c++ also (c# and c++ uses it, as
interoop)
The question is how to add Util.dll into wix installer,
When I copy/paste this dll into C:\ProgramFiles\SystemWOW64\ (the msiexec.exe directory) all works fine, but its a bad workaround which I would to avoid.
What I've tried:
1) Add as reference to the MSI project and include as:
<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Fragment>
<Binary Id="CPlusPlusAction" SourceFile="$(var.CPlusPlusAction.TargetDir)$(var.CPlusPlusAction.TargetName).CA.dll"/>
<Binary Id="CSharpAction" SourceFile="$(var.CSharpAction.TargetPath)"/>
<Binary Id="Utils" SourceFile="$(var.SolutionDir)/$(var.Utils.Configuration)/Utils.dll"/>
<CustomAction Id="FunctionOne" Impersonate="no" Return="ignore" Execute="commit" BinaryKey="CPlusPlusAction" DllEntry="FunctionOne" />
<CustomAction Id="FunctionTwo" Impersonate="no" Return="ignore" Execute="commit" BinaryKey="CSharpAction" DllEntry="FunctionTwo"/>
</Fragment>
</Wix>
2) Add as reference to both projects with CopyLocal = true
I've googled a lot but still can't find the solution (Wix Doc, StackOverflow, msdn etc)
Thanks in advance

For C# managed custom actions I don't think you can add the native dll as a reference. So instead add it as content with action copy and I'm pretty sure DTF will package it up and make it available in the temp directory (current directory of the process) at custom action execution time.
For C++, I use the ISSetup.dll / ISSetupFile pattern from InstallShield or statically link the library if you can.

Thanks for answer guys, but finally I figured it out.
First of all you need to add this Util.dll to Msi binary table:
<Binary Id="Utils" SourceFile="$(var.SolutionDir)/$(var.Utils.Configuration)/Utils.dll"/>
If you are not sure use Orca for seeing it inside .msi file
Second as Christopher said for c# its enaught to RightClick -> Add Existing project -> Utill.dll, then DFS extract it during installation into C:/windows/installation/"CustomActionId" and everything works, but...
problem is with c++ side, the Wix isn't for this language, so you need to care of everything during installation, for example write code which will read the BinaryTable for installer, read data and clean all msdn it's a lot of code
so I prefer to write CLR wrapper for util,
Build Util as lib, so on c++ side its build inside CA.dll, and add as lib to wrapper, so now you can use wrapper.dll in c#

WiX dll embedding

I'm trying to embed a .dll into a wix installer that is used by other dlls during the install but will not be installed onto the customer's systems.
I've currently got
<Binary Id="AutomationUtils" SourceFile="AutomationUtils\bin\Release\AutomationUtils.dll" />
...
<CustomAction Id="Install" BinaryKey="InstallUILib" DllEntry="AutomationUtils;RunInstallerDLL" Return="check" Execute="deferred" />
but even if I take the other .dll out - WiX refuses to acknowledge the existance of the AutomationUtils .. even though it builds ok (but falls over when you try and run it).

The BinaryKey='InstallUILib' will refer to a Binary element with Id='InstallUILib'. The CustomAction/#DllEntry attribute is the name of the function entry point into the custom action .dll in the Binary element. That name needs that ::GetProcAddress() can access. I'm pretty sure a function named AutomationUtils;RunInstallerDLL is not valid.
If you're looking to do managed code custom action (where you probably need multiple .dlls) this article is okay. Otherwise, if you're creating a native custom action, I recommend creating a single .dll.

Post build events in Script#

I'm trying to create post build events to copy the final .js and .debug.js files for my script# projects into the proper directories. I can't use the regular output folder, since I have more than one project that references another project, and that always results in a build error (Unable to copy referenced script because it is being used by another process).
The problem is that the C# compiler appears to run the post build events BEFORE it writes the actual .js files, so they don't exist when the post build event happens.
Is there any other solution to make this work?

You can set up a DeploymentPath property in your csproj and the generated scripts will be copied there.
All of the logic is in here: https://github.com/nikhilk/scriptsharp/blob/cc/src/Core/Build/Tasks/ScriptCompilerTask.cs ... so another option is to customize the build task to exactly your requirements.
The latest work if you check out the github repo, also has the script# part of the build process done during the build step of an msbuild project, so that should free up the post-build step for you to do what you'd like with the generated scripts. See https://github.com/nikhilk/scriptsharp/blob/cc/src/Core/Build/ScriptSharp.targets. Again, its just msbuild stuff, so you could potentially customize the .targets file to your liking as well if it doesn't fit your needs.

I got around this by adding the "copy" command as a pre build step on the projects that were using the script# project output, then adding a dependency so that the script# project would be built first.

Setting web.config properties during build (not through publishing)

I'm trying to deploy an app using a Web Setup Project. The problem I'm running into is that the web.config file is never transformed. According to this post it's by design that transformation only takes place during a publish. How do I get the web.config properties to update correctly if building the Setup Project in turn calls the other assemblies build command?

I fixed it by adding a dummy web.Template.config file like Andriy K suggested in this post, and then calling TransformXml during my BeforeBuild event like so:
<Target Name="BeforeBuild">
<TransformXml Source="$(WebFolderName)Web.Template.config"
Transform="$(WebFolderName)Web.$(Configuration).config"
Destination="$(WebFolderName)Web.config" />
</Target>

The simplest option is to install a command-line xslt utility and launch it in the post-build action of your project. You could also use one of the many MSBuild XSLT tasks and add it into the .csproj file. (It's just an MSBuild script file; there are comments already in there near the bottom explaining how to customize the build.)
You could also perform either of these steps in the pre-build action of your setup project, instead of the post-build action of your web application. If you also use the publishing wizard, this second option may work better as it won't interfere with the normal XSLT transforming going on in the publisher.
Microsoft XSLT command-line utility: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=2fb55371-c94e-4373-b0e9-db4816552e41&displaylang=en
Example MSBuild XSLT Task: http://www.arlt.eu/blog/2007/10/01/msbuild-xslt-task/

Using an external tool for C# builds in Visual Studio

When using Visual Stdio 2008, you can make a C++ project build with an internal tool rather than having the IDE invoke MSVC directly. This improves the consistency of builds across platforms if a cross-platform build system is used.
However, I cannot figure out how to do the same as a C# project. It would be possible to simply register it as a native project with C# sources, however, you lose some of the advantages gained through having a C# project. More importantly, it will mean that allowing a project to build both directly and with an external tool (which is sadly necessary) will require two separate projects, rather than merely creating an alternate build configuration to invoke the external tool.
Does anyone know if it's possible to prevent Visual Studio from invoking csc by itself and instead call an external tool?
EDIT: Apparently there has some misunderstanding. The goal here is not to compile anything outside of Visual Studio. Instead, it's to allow Visual Studio to serve as the IDE but not the build system. There is already a (Scons-based) build system capable of compiling the C# and C++ sources, and Visual Studio has been configured to invoke Scons for compilation of C++ projects. I'm trying to configure it so that when you hit the 'Build' button, it will invoke Scons for the C# projects as well as the C++ ones.

Edit: Your question is still answered using MSBuild(if you are simply looking to compile outside the IDE). The IDE(Visual Studios) is simply a "fancy" way of constructing the build files that are built by MSBuild. Visual Studios isn't building the files, it simply is invoking MSBuild which ships with the .NET Framework 2.0 and up which compiles your code based on the project file that you create. If Scons can read and process an MSBuild file then I'm sure you can invoke it to build your project. But considering the fact that C# is a Microsoft language, I think you will be hard-pressed to find a value-add in not using MSBuild since I'd assume both the language and build tool are very tuned to work together. - End Edit
You can use MSBuild to compile your C# project. If you open your .csproj file in a text editor you will see that it is a MSBuild file. If you want to write some C# outside of the IDE you can construct a build file using the .csproj file as a starting point and invoke MSBuild to compile your apps. The IDE is just a way of abstracting the editing of the MSBuild file away for you.
If you are really industrious you can create a set of custom tasks to do things in your custom build process like move files around and versioning. MSBuild Community Tasks are a great example of using custom code to do task for you during MSBuild.

Given all the other answers, what MSBuild does when either VS or MSBuild perform a build can be found in the Targets files that ship with .Net. These can be be found in the FrameWork directory on your system. In my case:
C:\Windows\Microsoft.NET\Framework64\v3.5
Contains Microsoft.Common.targets among others. This file contains the following snippit:
<!--
============================================================
Build
The main build entry point.
============================================================
-->
<PropertyGroup>
<BuildDependsOn>
BeforeBuild;
CoreBuild;
AfterBuild
</BuildDependsOn>
</PropertyGroup>
<Target
Name="Build"
Condition=" '$(_InvalidConfigurationWarning)' != 'true' "
DependsOnTargets="$(BuildDependsOn)"
Outputs="$(TargetPath)"/>
This means that redifining this Target you can make MSBuild an VS do anything you want. The top of the mentioned file contains an important messagge:
Microsoft.Common.targets
WARNING: DO NOT MODIFY this file unless you are knowledgeable about MSBuild and have
created a backup copy. Incorrect changes to this file will make it
impossible to load or build your projects from the command-line or the IDE.
This file defines the steps in the standard build process for .NET projects. It
contains all the steps that are common among the different .NET languages, such as
Visual Basic, C#, and Visual J#.
My suggestion would be to read all you can about MSBuild and it's build file syntax and try redifining the Build target in your project(s). My impression is that after reading up on MSBuild you'll probably find an easier way to meet your requierements. You can find an example of redifining a Target like this in one of the answers of this so question .
Edit:
How to redefine a target?
Redefining is essentially defining the same target 'after' it has been defined. So for instance in your .*proj file(s) define a Build Task after the <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" /> line that imports all targets needed to in this case build a C# project. An example could be
<Target
Name="Build"
Condition=" '$(_InvalidConfigurationWarning)' != 'true' "
DependsOnTargets="BeforeBuild"
Outputs="$(TargetPath)">
<Exec Command="nmake" />
</Target>

I found a question in the same direction here, where it is suggested to edit the registry. I am pretty sure there is no other way to change the compiler used by Visual Studio because there is no trace of csc.exe in any solution, config, csproj file or whatsoever, nor in the Visual Studio 9.0 folder / subfolders within the Program Files dir.
Registry locations can be found in:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\74ACAA9F1F0087E4882A06A5E18D7D32
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\9055DA7481CC1024CB23A6109FD8FC9B
but those keys may differ dependng on your installation. Conclusion: changing the compiler used by VS seems next to impossible.
Addition: The following MSDN article deals with the same question for an custom C++ compiler, and Ed Dore's answer seems to confirm my theory that there's no way to choose an custom compiler for use within VS.

Under 'Tools' > 'External Tools' you should be able to define an outside tool to do activities for you. The Command should be the path to the executible for your external tool.
Hope this helps some.

You don't have to maintain different project files to build using an external tool. MSBuild is designed to build using the same project files that Visual Studio uses.
Here's an article that describes it.
Customize Your Builds in Visual Studio Using the Standalone MSBuild Tool
It's for VS2005, but should apply to VS2008 as well.

Looking through the answers, it seems clear to me that integrating scons into Visual Studio in a way that is compatible with the debugger and so on is not going to happen...
An option you might to consider, and I understand you don't want to change build systems, but bear with me, is to use a meta-build system, ie 'cmake'. http://www.cmake.org/
Cmake doeesn't actually build the project. What it does is to create build files for you, that you can use to build the project, and on Windows, the build files it creates for you are: Visual Studio project files. You can simply load those directly into your IDE, and compile, and use normally!
CMake is I feel very easy to use, and provides a high level of transparence and maintainability.
The exact same CMakeLists.txt files on linux will causes linux makefiles to be generated.
On mingw, they can generate mingw makefiles.
There are numerous generators available within cmake. The list is here:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#section_Generators
http://springrts.com is a huge opensource rts game that used to use scons as its cross-platform build system and now uses cmake.
I understand that you don't really want to have to change build systems, so it is a medium to long term solution.
Cmake is in any case one more option, to add to those of using a custom build tool, or using msbuild, or running the scons build from the commandline by hand.

Edit your project file and update the CscToolPath keys to point to the directory containing your tool and add CscToolExe keys that holds the name of the directory:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|.NET 3.5' ">
.
.
.
<CscToolPath>path\to\custom\tool\directory</CscToolPath>
<CscToolExe>exe name</CscToolExe>
.
.
.
</PropertyGroup>
I have not tested this, and the CscToolExe key may cause problems, in which case I would simply rename the external tool executable to "csc.exe".

You can build your solution from the command line like this:
C:\WINDOWS\Microsoft.NET\Framework\v3.5>msbuild.exe "C:\path\Your Solution.sln"