Ideally I'd be grabbing the outputs from the project spec itself, but heat.exe doesn't seem to support contentproj files as a project type, nor does it pick up the content if I pass in the game's main csproj.
Currently I have a pre-build step calling heat on the output folder, but that (a) feels dirty, and (b) produces a bunch of File tags referencing the source paths relative to the output folder, such that the build fails when it can't find them relative to the WiX project's folder.
I should note that I'm using Votive and my project layout looks like this:
- Main solution
- XNA "Metaproject" Folder
- Game
- bin/x86/Release (GameContent output appears here)
- GameContent
- WiX Project
I would very much like to minimize the number of times I have to specify a path like "../../Game/Game/bin/x86/Release/Content", because that's error-prone and depressing to type out. Prods in the right direction appreciated!
Assuming a contentproj is just a collection of files, what you can do is add the harvesting directly within the wixproj that is creating the installer:
<PropertyGroup>
<HarvestDirectoryNoLogo>true</HarvestDirectoryNoLogo>
<HarvestDirectorySuppressFragments>true</HarvestDirectorySuppressFragments>
<HarvestDirectorySuppressUniqueIds>true</HarvestDirectorySuppressUniqueIds>
<HarvestDirectoryAutogenerateGuids>true</HarvestDirectoryAutogenerateGuids>
</PropertyGroup>
<ItemGroup>
<HarvestDirectory Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' "
Include="$(SolutionDir)\GameContent">
<DirectoryRefId>INSTALLDIR</DirectoryRefId>
<SuppressRootDirectory>true</SuppressRootDirectory>
<PreprocessorVariable>var.GameContentDir</PreprocessorVariable>
<ComponentGroupName>GameContent</ComponentGroupName>
</HarvestDirectory>
</ItemGroup>
You will need to add this manually to the wixproj file and you can repeat the HarvestDirectory for each directory if you require more than one.
To set the var.GameContentDir pre-processor variable edit the DefineConstants property:
<DefineConstants>GameContentDir=$(GameContentDir);</DefineConstants>
which will set the pre-processor var to the msbuild property:
<GameContentDir>$(SolutionDir)\GameContent</GameContentDir>
which means you can then modify this dependant on the build configuration. If you don't need to modify the path, just set a static value in the <DefineConstants> property.
This will then generate a wxs file in the obj directory each build which is then included assuming you have included the ComponentGroupName. If you have included the one you previously generated in your wixproj remove it as you will get conflicts if the ComponentGroupName is the same.
Related
I'd like to specify an environment variable for use in the source path (library path) at a project level.
We often have a couple of versions checked out of our SVN repository at the same time in different directories, and I'd like to specify the repository root for a project in relative terms at a project level. I could then use that path in a project's source path and I wouldn't have to include indecipherable dot dot slashes (..\) in paths.
For example, say I have checked out trunk to c:\projects\trunk. Then underneath there I have a project in <repositoryroot>\Foo\Bar\ under trunk which uses the Delphi Spring framework under <repositoryroot>\components\external\Spring4d. I end up with a whole bunch of directories in the search path with ..\..\External\Spring4D\Source at the beginning. For example ..\..\External\Spring4D\Source\Base\Collections. I would like to be able to be able to use ${Spring4D} instead, producing ${Spring4D}\Base\Collections\, which is much less wordy and it means that if you move a project or component you can change one value and it updates all paths.
I know that you can do this on a Delphi level by specifying paths in Delphi's environment variables, but I would like to achieve the same thing on a project level or repository level.
Does anyone have any ideas on how to achieve this? Are there any settings or even add-ins that would allow this sort of functionality?
You can manually edit your project file (.dproj) and add a variable there:
<PropertyGroup>
<MyVariableName>MyVariableContent</MyVariableName>
</PropertyGroup>
Later on, you can refer to the content of that variable:
<DCC_UnitSearchPath>C:\Components;$(MyVariableName)</DCC_UnitSearchPath>
You can also define a new environment variable (SystemPropertiesAdvanced.exe -> Environment variables -> Add) and then refer to that variable using the same syntax, e.g.:
<DCC_UnitSearchPath>C:\Components;$(PATH)</DCC_UnitSearchPath>
(Note that it is a very bad idea to use PATH here, it's only an example of a variable which will exist in your environment.)
You could also employ some cmd script magic to to create environment variables that point to those subdirectories and at the end call the IDE, so these environment variables are available in the IDE in the same way as global environment variables would be (see pepak's answer for that).
Pointers:
%0 is the name of the current cmd file
use tilde for file name parts
The snippet below is taken from a TFS build definition file.
<mtbwa:CopyDirectory Destination="[BuildDetail.DropLocation]" DisplayName="Copy Files to Drop Location" Source="[BinariesDirectory]..\Packages" />
Regarding the source attribute, I want to set the value to a particular folder destination, using an existing variable and then going up one level.
If the variable [BinariesDirectory] was equal to "C:\TFS\Binaries", I am trying to set the source to "C:\TFS\Packages", but it just does not understand ..\ and will actually look for a folder at "C:\TFS\Binaries..\Packages"
How can I go up a folder level?
Thanks in advance
Means that it elavates to parent folder, then submerge to PACKAGES
use double \
When I try to build my project, I get the following error:
error : Unable to update the AssemblyFileVersion for c:\builddir\MyProject\AssemblyInfo.cs: No stub entry for AssemblyFileVersion was found in the AssemblyInfo file.
I found this article, which implies that a "stub" property is required. So, in my AssemblyInfo.cs, I tried to specify one:
[assembly: AssemblyFileVersion("1.0.0")]
However, it isn't recognised. I finally came across this article, which says that you can't use the AssemblyFileVersion property with the CF. The targets file used by the build script is also used for building other, non CF projects, and needs to update the FileVersion for them.
Is it possible to put something in the AssemblyInfo.cs file, the target file or the build script that stops this from being an issue?
Yes, something like this:
#if !(WindowsCE || PocketPC)
[assembly: AssemblyFileVersion("1.0.0")]
#endif
If using the preprocessor in the manner described in the other answer doesn't work for you, consider putting the AssemblyFileVersion attribute into a separate source file, and conditionally including that source file in the project:
<Compile Include="AssemblyInfo.cs" />
<Compile Include="AssemblyInfo.AssemblyVersion.cs"
Condition="
'$(TargetPlatform)' == 'WindowsCE' OR
'$(TargetPlatform)' == 'PocketPC'"
/>
I'm not sure if there is already a property you can use in the project file, or if you would need to declare your own (perhaps $(Platform) is used for this?)
This will hopefully be an easy one. I have an F# project (latest F# CTP) with two files (Program.fs, Stack.fs). In Stack.fs I have a simple namespace and type definition
Stack.fs
namespace Col
type Stack=
...
Now I try to include the namespace in Program.fs by declaring
open Col
This doesn't work and gives me the error "The namespace or module Col is not defined." Yet it's defined within the same project. I've got to be missing something obvious
What order are the files in the .fsproj file? Stack.fs needs to come before Program.fs for Program.fs to be able to 'see' it.
See also the start of
http://lorgonblog.spaces.live.com/blog/cns!701679AD17B6D310!444.entry
and the end of
http://lorgonblog.spaces.live.com/blog/cns!701679AD17B6D310!347.entry
I had the same problems, and you are right, the order of the files is taken in account by the compiler. Instead of the Remove and Add pattern, you can use the Move Up / Move Down items in the context menu associated to the .fs files. (Alt-Up and Alt-Down are the shortcut keys in most of the standard key-bindings)
All of the above are correct, but how to do this in VS2013 is another question. I had to edit my .fsproj file manually, and set the files in exact order within an ItemGroup node. In this case it would look like this:
<ItemGroup>
<Compile Include="Stack.fs" />
<Compile Include="Program.fs" />
<None Include="App.config" />
</ItemGroup>
I had the same issue and it was indeed the ordering of the files. However, the links above didn't describe how to fix it in Visual Studio 2008 F# 1.9.4.19.
If you open a module, make sure your source file comes after the dependency in the solution explorer. Just right click your source and select Remove. Then re-add it. This will make it appear at the bottom of the list. Hopefully you don't have circular dependencies.
I'm using Visual Studio for Mac - 8.1.4 and i've noticed that some .fs files are not marked as "Compile". You can see this by Viewing Build Output and see if all your files are there and in the correct order.
I've had to manually make sure certain files are marked with "Compile", and have had to move them up and down manually until it "takes".
I have been trying to make a task in my TFS builds more generic, and one of the things I am trying to do is copy some files to different directories depending on the build using the task. I toyed with the idea of using properties, but I couldn't think of a way to do that cleanly, so I tried to go with using item metadata, as I've been able to do so in another place in the same target file I'm working on, only this time, I'd like to use properties.
Here's what I want to do:
<ItemGroup>
<DestinationParent Include="$(DeploymentPath)">
<DestinationParentPath>$(DeploymentPath)</QuartzParentPath>
</DestinationParent>
</ItemGroup>
And later in the build, I tried to copy some files to the destination folder by referencing the item metadata:
<Copy SourceFiles="#(FilesToCopy)" DestinationFiles="#(FilesToCopy->'%(DestinationParentPath)\Destination\%(RecursiveDir)%(Filename)%(Extension)')" ContinueOnError="false" ></Copy>
Unfortunately, after the build runs, my BuildLog shows the following:
Copying file from "$(BinariesRoot)\%(ConfigurationToBuild.FlavorToBuild)\<File being copied>" to "\Destination\<File being copied>".
%(DestinationParentPath) had expanded to an empty string, for whatever reason. Using %(DestinationParent.DestinationParentPath) produced an error, telling me that I should simply be using %(DestinationParentPath). $(DeploymentPath) is expanded to the correct string as expected in several other places in the build.
Another source of confusion is that using %(ConfigurationToBuild.FlavorToBuild) yielded the correct value, i.e. Test, as can be seen in the following:
EDIT: this is defined under the root node Project, whereas the ItemGroup with DestinationParentPath is defined under a Target node. Does this also make a difference?
<ItemGroup>
<ConfigurationToBuild Include="Test|Any CPU">
<FlavorToBuild>Test</FlavorToBuild>
<PlatformToBuild>Any CPU</PlatformToBuild>
</ConfigurationToBuild>
</ItemGroup>
It does not seem as though the Include attribute is relevant when you're only interested in the string in the item's metadata since I'm pretty sure "Test|Any CPU" does not reference any actual file.
So once again, why is %(DestinationParentPath) expanding to an empty string?
EDIT: I forgot to mention that I also tried hard-coding the actual path for DestinationParentPath, but this still resulted in %(DestinationParentPath) expanding to an empty string.
EDIT: this is defined under the root node Project, whereas the ItemGroup with DestinationParentPath is defined under a Target node. Does this also make a difference?
Yes, it makes a difference. The ability to define an ItemGroup inside a Target is new to msbuild 3.5. Despite looking declarative, it's actually executed at runtime just as if you'd called the old style CreateItem / CreateProperty tasks. That alone leads to potential issues: you need to consider when the containing task is (first) called. Order of operations is not always obvious to the naked eye. May be wise to make the task where you use %(DestinationParentPath) dependent on the task where it's created, even if there's no "logical" dependency.
In addition, there are the age-old msbuild scoping quirks/bugs. Dynamically created properties & items are not visible to "sibling" tasks. Also, items updated in nested builds aren't always bubbled up.
Check out the workarounds in the links, you should be able to find something that works for you even if it's icky.