I've spent a couple of days exploring option sets (again) in XE3. They look really clever but either they are (still) broken or its me. What I wanted to do was to create a common option set file for a bunch of projects, say CommonOptions.optset. This is easy to create and edit using the View | Configuration Manager item. In this options set file I put a set of relative search paths such as:
..\..\source1;..\..\source2;
etc. These paths are proven to work when entered into the DEBUG or BASE build configuration directly. When I use the Configuration Manager to apply this common option set as a reference, the paths do not work. If I repeat the application using 'Modify Values' it works fine. To be sure, I deleted the DPROJ (and all the .local stuff too) and let Delphi recreate the DPROJ before applying the option set file as reference again. Still no luck.
I have several libraries with 10's of DPROJ's all of different vintages so I really do need a common way of specifying compiler options, don't include version info etc.
Has anyone got this reference thing to work?
Referenced option sets are implemented as plain MSBuild imports. Therefore, all relative paths are relative to the importing project file. You can think of option sets as build configurations from which build configurations in referencing project files may inherit.
Related
I'm attempting to modify my build process file for TFS 2010. I have a flag that is set when queuing the build, and when said flag is set, I want to create a Label, and add all the source files in the compiled project to that label.
On sequential builds, with the flag set, I than want to replace older source files in said label with anything new in the changeset being compiled.
I've been attempting to do this with LabelSources with no luck, and there is but vary poor documentation on either LabelSources or LabelWorkspace (whats the difference?).
Here's what I currently have:
<mtbwa:LabelSources
Child="[LabelChildOption.Replace]"
Comment="Published to Container"
DisplayName="Create Container Label"
sap2010:WorkflowViewState.IdRef="LabelSources_1"
Items="[{"$/Foo/LabelTest/Sandbox/"}]"
Name="[String.Format("{0}-{1}", LabelName, Version_Container)]"
Recursion="[RecursionType.Full]"
Scope="$/Foo"
mva:VisualBasic.Settings="Assembly references and imported namespaces serialized as XML namespaces"
Version="T" />
It definitely hits the action, but no labels can be found after the fact.
Any help would be much appreciated. and Any tangible documentation, other than Class Documentation with sparse definitions would also be greatly appreciated
Edit 1: Tried to clear up my goal.
What you are trying to do is built into the existing template. There should be an option in the process definition that refers to Clean Sources which will be set to True.
This option controls wither the build sources get cleaned, deleted and start afresh. Or if a differential is done.
If you have a lot of source code you can set clean sources to false and save a bunch of time getting the code.
You can also speed the build by placing a TFS Proxy on the build box which will cache the files and make a clean build quicker.
In my experience, Most of the built-in activities are poorly-documented for a reason - their only well-tested use case is their use inside TFS' built-in templates (DefaultTemplate.11.0.xaml, etc.). I'm afraid you're going to have to write some custom code, in the form of a custom activity, powershell script or something, to achieve other goals.
That said, I don't really understand the process you're trying to set up. Do you just want to have a label set as your latest-successfully-built sources? Why not use the one created automatically by the build itself?
I am setting up a TFS 2012 Build server. I am using some extensions (NUnit Test Adapter). Per the instructions, I have added the dlls to a common folder in TFS, and configured the "Version Control Path to Custom Assemblies" on the build controller to reference the correct folder in TFS.
Everything works, BUT: According to the docs, I can create subfolders under my "Path to custom assemblies" folder, and the controller should pick them up.
That doesn't seem to be working for me. If I put the NUnit support in the root, it works, in subfolders, it does not.
I would like to use the subfolders feature so that I can keep each set of extensions/custom build targets, etc separate.
Does this just not work, or am I missing something?
Edit
As requested, here is a reference to the documentation where I found the information:
http://msdn.microsoft.com/en-us/library/vstudio/ee330987(v=vs.120).aspx#custom_process
Here's the passage:
To enable your build processes to leverage these kinds of code, check the binaries in to the folder (or any of its descendant folders) that you specify in the Version control path to custom assemblies box.
It turns out that the documentation is just wrong -- all of the dlls must go into 1 folder.
http://social.msdn.microsoft.com/Forums/en-US/0059bc66-d3c9-42e6-8d8a-dd22f3416e07/version-control-path-to-custom-assemblies-doesnt-use-subfolders?forum=tfsbuild
I do understand that helps to ensure that you don't get duplicate dependencies with different versions -- makes sense. It just makes it a little tougher to know what depends upon what if you add a few extensions. Seems to work fine using a single folder, though.
I am unable to figure out how to change default build/compile settings. The little default checkbox in the lower left of the project options dialog is gone. The documentation states:
The Default checkbox that appeared at the lower edge of many Project Options pages has been removed from the product. If you want to specify options as the default for multiple projects, the suggested alternative is to use option sets instead.
I'm going round and round about "Options Sets", "Configuration Manager" etc.. Is this even possible? What does "specifying options as the default for multiple projects" mean? If I have multiple projects then that means those projects and their options exists, how can I set a default value to something already set? What about new projects?
That feature really has gone and there is nothing like it any more in the product, to the very best of my knowledge. I think the best you can do is as follows:
Create a new project.
Change the project settings to whatever you want them to be.
Change anything else in the default project that you don't like, for example { Private declarations }.
Add this project to the repository.
use File | New | Customize to move this project template onto the File | New menu for easy access.
Project->Options->Target. You can set up a base configuration, and then provide different options that differ from the base for Debug and Release. You can also create custom option sets, which means that they're different from the standard Debug and Release. You can also have different configurations based on different targets (VCL app's Debug build has different options than a FMX app's Debug build, etc.)
To change the default options first starts with defining "default". You can start as low as the "base configuration" through Project->Options->Delphi Compiler, and then choosing the All Configuration target. You can refine it somewhat by altering the base configuration for the Debug and Release configurations. You can also define your own option sets, using the Save button next to the Target list.
Your specific question about "specifying options as the default for multiple projects" means is the base configuration. From there, you refine those base options to give you debug settings and release settings (which can also be saved as your initial defaults, and refined on a per-project basis).
So, for a specific answer, you can change the default by modifying the base configuration, or by getting more specific by modifying the debug or release configurations that inherit from that base, depending on what your end result needs to be and what you're trying to accomplish.
I have a complex project group that has about 10 "final" build configurations configured in a tree, where each node has its own option set. Something like this:
Base
Release
Release Generic 1
Release Final 1
...
Release final 5
Release Generic 2
Release Final 6
...
Debug
same as release, but for debug
so, all base, Release, Release Generic X, Release Final Y have their own option set saved in files and added as reference. So you will have
base.optset
Release.optset
Release Generic 1.optset
Release Final 1.optset
..
The main differences between these option sets are various compiler defines enabling/disabling certain features that are organized in the tree mentioned above (hence the build targets and the option sets) and obviously search paths that include the needed stuff.
So each option set also contains different search paths that depend on the respective build configuration.
There are over 100 projects in the project group and most of them relate to one another on different level of configurations, so there are also a bunch of Build Groups, but this is irrelevant for the question as right now I'm trying to build the projects one at a time.
The problem is that every option set is configuring the search path. Up to and including "Release Generic 1.optset" the search path is correctly updated and used. However, the "Release Final 1" and siblings don't get the search paths introduced by "Release Final 1.optset". (I know this because I looked at the compiler messages and checked the parameters passed to dcc32) It appears like the option set is ignored.
Everything is configured with "inherit=true" in the option set.
There is nothing specific in the build configurations, nowhere. Every project uses the configuration in the IDE and option set files only.
Is this issue/limitation documented anywhere/known about? Is there a workaround? Other than applying the option set as value and not by reference.
Thanks.
later edit:
I decided to implement a pretty ugly workaround in order to get moving: basically, replicate teh configuration from "Release Generic 1.optset" into each "Release Final ?.optset"
this has the major disadvantage of having to edit 5 option set files propagating the same modification, when in need of adding something to "Release Generic 1.optset"
Finally I managed to figure out the problem. It's actually a bug in the Delphi IDE in that it messes up the imports in the dproj file.
Specifically, if an optionset is added once, it will not be maintained with the necessary import condition for the rest of the configs.
This usually happens when you add/delete a configuration, the dproj gets busted and optset files no longer get imported for all the configs.
But once your configs are stable and you no longer change them, the dproj remains stable.
I mocked up an application to validate dproj files against these issues, verifying that each config has its optset files in an import directive. I'm yet to make it auto-correct this, as I'm rather busy. But once I manage to find the time, or if there are more people affected by it and require an automatic fix, I'll try to make a release.
Until then, if you noticed the option set is not applied for a specific config, simply find the configs id in dproj (something like Cfg_10 ) and see if you can find an
<Import Condition="'$(Cfg_10)'!='' And Exists('optset file path name')" Project="optio file path name"/>
if not, then add it after the other <import calls
Has anyone used WiX to generate an installer for an ASP.Net MVC website? Do you harvest files from the web project? I can’t find any good examples of this being done. There doesn’t seem to be a documented way to include all the right files, only the right files and put them in the right place.
If you add the website project as a reference in the installer project, and set harvest=True in the properties, then all the website files are captured, but there are issues:
Some files that should not be copied are included, e.g. packages.config, Web.Debug.config There doesn’t seem to be any clear or simple way to exclude them (as per this discussion).
The .website dll file is in the wrong place, in the root rather than the bin folder (as per this discussion)
However if you do not use harvesting, you have a lot of files to reference manually (e.g. Under \Content\ alone I have 58 files in 5 folders. Most of that is jQuery UI) and they change from time to time, and errors and omissions could easily be missed from a WiX file list. So it really should be kept in sync automatically.
I disagree with the idea that the list of files should be specified explicitly in WiX and not generated dynamically (which is what seems to be suggested at the first link, the wording isn't very clear). If I need to remove a file I will remove if from the source control system, there is no need to do the extra work of maintaining two parallel but different catalogues – one set of files in source control, and the same files listed in WiX. there should be one version of the truth. All files in the website's source tree (with certain known exceptions that are not used at runtime e.g. packages.config) should be included in the deployment.
For corporate reasons I don't have much choice about using WiX for this project
In our MVC 3 project we use Paraffin to harvest files for the installer. For example, you can use "-ext " to ignore the files with extension , use "regExExclude " to ignore the file name matching the regular expression, etc.
Paraffin also keeps the proper structure, all your files would be in the correct folder as they appear in your project.
I use a program that I wrote called ISWIX that makes authoring wxs merge modules a simple drag and drop operation like InstallShield. I then consume that merge module in an installer that handles the UI and IIS configuration.
I also have postbuild automation that extracts the content of the MSI and compares it against what the project published. If there is a delta I fail the build and you have to either a) add it to the wxs or b) remove it from the publish.
I find that the file count churn from build to build is minimal and that this system is not difficult to maintain. The upside is everything remains 100% intentionally authored and files don't ever magically add or remove from the installer unless you intended them to. Dynamic installer generation isn't worth the risk and most people who argue that it is don't even know what those risks are.