I have a WiX project in VS2013.
The output directory in wixproj is:
bin\$(Platform)\$(Configuration)\
by fact it is
\bin\x64\Release\en-us
How and where I can change the real output to
\bin\x64\Release\
?
Pass ; (single semicolon) as a list of cultures to build.
WiX interprets it as a single, empty culture code meaning "neutral culture".
First, the reason why this is happening. When you specify multiple cultures to build (for example, en-US and ja-JP), Visual Studio needs a way to differentiate between the installation packages generated. This is the reason why you get the output path with the culture string appended to it.
If you have a single culture, you can specify it in Project Properties→Build→General→Cultures to build.
So one of the solutions is to use a single culture. In cases where this is not possible, you can modify the wix2010.targets and edit the target Link. The original target has this code at line 2497, under Light task:
OutputFile="$(TargetDir)%(CultureGroup.OutputFolder)$(TargetName)$(TargetExt)"
You then need to remove the %(CultureGroup.OutputFolder). Don't forget to differentiate between different cultures. One solution for this differentiation would be this (not tested):
OutputFile="$(TargetDir)$(TargetName)%(Culture)$(TargetExt)"
Related
I am looking at using MSBUILD from a command line to run the schema compare (*.scmp)
Within the solution we have several databases and the team aren't always that great at remembering to check changes (stor procs, tables etc..) into the solution. Although Visual studio can show the comparison, I can't find a way of exporting the list of errors, for me to chase the team about. Screen shots seem to be the only way.
I thought That I would see if there were any tools in order to produce a list of differences. I came across an example on the following:
http://blogs.msdn.com/b/ssdt/archive/2014/07/15/msbuild-support-for-schema-compare-is-available.aspx
I saw this example:
C:\SampleProject > msbuild /t:SqlSchemaCompare /p:SqlScmpFilePath="d:\sc.scmp" /p:target="d:\target.dacpac" /p:TextOutput="d:\1.out" /p:Deploy="true
However I can't get it to work. When I run the equivalent against my particular set up I get:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets(843,5): SchemaCompare error : The tar
get participant is invalid or empty. at Microsoft.Data.Tools.Schema.Tasks.Sql.SqlSchemaCompareTask.Execute() [C:\TFS\Argon_Main Solution_Latest R
elease\Source\Blah\SomeData.DataDatabase.sqlproj]
Has anyone got any ideas?
Cheers
I ran across this issue the other day. Turns out the problem was i needed to use the VisualStudioVersion command line argument.
msbuild /t:SqlSchemaCompare /p:VisualStudioVersion=14.0 /p:SqlScmpFilePath="MySchemaCompare.scmp" /p:target="MyConnectionString" /p:TextOutput="..\output.out"
Your Microsoft.Data.Tools.Schema.SqlTasks.targets file should be located at C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\{Your VS Version}\SSDT
I realize it's been a while since this was asked, but I'll answer anyway.
Firstly, it's unclear to me what you're trying to compare exactly. Do you want to compare two versions of the project to see the differences, or are you comparing a project to a database?
One thing I noticed is that you're specifying the target twice in the command line. Firstly, the .scmp file referenced via the SqlScmpFilePath parameter contains a source and target. Secondly, the target parameter also defines a target. The target parameter will override whatever is in the .scmp file.
Maybe this is intentional, though, if your .scmp file has the right source but you want to specify the target in the .dacpac file.
The .dacpac file can be found in the bin\Debug or bin\Release folder of your SSDT project after a build. For your command to work, you'll need to make sure "d:\target.dacpac" exists and is such a file.
The .scmp file is created by doing a Schema Compare in Visual Studio and then saving the comparison window after selecting the source and target. For your command to work, you'll need to make sure that "d:\sc.scmp" exists and is such a file.
Please let me know if this helps.
I'm currently trying to make splint available as an external tool in Visual Studio 2010.
It has problems with finding all includes for the file, since it seems that the INCLUDE variable is only set at build time and I haven't found any other possibility to extract the include files in any way.
My question: Would there be any way to extract the IncludeDir field from the current file's project's Properties page, ideally with the VC++'s AdditionalIncludeDirectories?
Note also that AdditionalIncludeDirectories is per file, as it can be changed for individual source files as well as on the project level, and if it contains macros it can evaluate differently for each source file too!
I'm not familiar with driving the MSBuild objects via the API, but that's used by the IDE. Whether that way or by simply running MSBuild.exe, you need to get it to figure out all the properties, conditions, etc. and then tell you the result. If everything is well behaved, you could create a target that also uses the ClCompile item array and emits the %(AdditionalIncludeDirectories) metadata somehow such as writing it to a file or passing it to your other tool somehow. That's what's used to generate the /I parameters to CL, and you can get the same values.
If things are not well behaved in that necessary values are changed during the detailed build process, you would need to get the same prelims done just like the ClCompile target normally does, too. Or just override ClCompile with your own (last definition of a target is used) so it certainly is in the same context.
Either way, there are places where build script files can be automatically included into all projects, so you can add your stuff there or use a command argument (I think) to MSBuild to add another Include.
—John
With Makefiles I'm used to being able to write things like:
includedir=$(shell pg_config --includedir)/server
to run an external program, pg_config, with argument(s) --includedir, and include the result in a variable or as part of a variable. So if pg_config --includedir output /usr/include to stdout, the value of includedir would become:
includedir=/usr/include/server
Is there any way to do the equivalent with a Visual Studio project? Run a command, get the result, and substitute it into a property?
I find myself having to edit properties pages all over the place - changing the include directories and library directories for both the x86 and x64 configurations of a project whenever I want to build an extension against a different PostgreSQL version. It is intensely frustrating.
I want to be able to put something like this into Configuration Properties -> C/C++ -> General -> Additional Include Directories:
%(shell pg_config --includedir)
or even better:
%(shell %(PG_CONFIG) --includedir)
where %(PG_CONFIG)'s location is defined in a single place for each platform in the project.
So I'm looking for at least user-defined macros, and preferably the ability to invoke a command line tool and replace the macro with the resulting standard output.
(Preferably in a way that doesn't involve delving into semi-documented UI elements that move and get renamed in every VS version, and that appear and disappear from the various Express editions).
This has been possible in Makefiles for 20 years, there must be a way to do it in VS, right? Or do "Real Windows Developers" generate their VS projects with scripts and build them using MSBuild?
I've looked at some similar questions without finding much of use, e.g.:
Visual Studio - Where to define custom path macros?
In particular, I'm aware of property sheets (View -> Other Windows -> Property Manager), but they don't seem to provide a way to set a value in just one place, they're still per-configuration and per-architecture, so if you have four configurations and two architectures it gets awkward. Unlike with the normal project property editor you can't even apply a change across a group of architectures/configurations, either.
I could use a VS extension, but they require installation into the user's VS, can be version-specific, and seem like a very big hammer for a small problem.
I find myself having to edit properties pages all over the place
That bugged me to no end as well. Property sheets to the rescue! When setting up a major solution in VS10, for example, I had every project pull in a settings.props that contained the common settings, made in only one place. Then go through all the generated or imported projects and kill any explicit value (even if blank) for everything possible. That way things will inherit from property sheets. Select "all configurations" and on each properly use the drop-down to "inherit from...".
I have property sheets for each special library too, just defining the proper #define, include paths, lib paths, etc. Projects that use that particular external lib simply use that property sheet. Users are told, in the worst case, to “edit the XML to change the path to where you have Boost”.
As for setting such a properly to a dynamic determined value, you can do that too. There are property functions you can use.
It sounds like you're going down the same path as I did.
More notes: “prop sheets are per configuration/platform”: If you include a prop sheet at the top-level node for the project itself (not the Debug|Win32, etc. child nodes) it will include it into all current configurations at once. If you edit the properly page, you can choose Multiple or All configurations on the Property dialog box, just as with the usual project use of the Property dialog.
“Custom user macros are well hidden” A property page shows up for that when in a property sheet you created, but not when opening property dialog on a proj file as in the normal File View. The macro will be set in one place (the prop page) and usable as a $(name) in all projects that include it, and even in other property pages that come later in the evaluation sequence.
Let me know how it goes. You should be able to do everything you asked.
—John
In addition to #jdlugosz's answer:
It looks like the traditional way to do this with Visual Studio, before the advent of property functions, was to write a new MSBuild Task. The task can potentially do things like modify a property sheet.
MSBuild supports "inline tasks" where the task code is in the MSBuild project file, rather than a separate assembly, so it might not be neccessary to create a new subproject just for the task.
There are a bunch of built-in tasks, like Exec and CreateProperty that may be useful.
The docs say that:
[The Exec task] is useful when a specific MSBuild task for the job that you want to perform is not available. However, the Exec task, unlike a more specific task, cannot gather output from the tool or command that it runs.
... but that seems to be outdated/wrong so you don't need horrible workarounds.
So, prior to .NET 4.5 I'd probably have to write a custom task for this simple job, because there's no way to feed the command stdout/stderr into the CreateProperty task or have Exec create a property directly. But in 4.5 it looks like I can do it directly. At least in VS Express support for tasks etc is very limited so you'll probably land up editing the XML.
That the logical follow-up for the my previous question: "How to check all projects in solution for some criteria?"
I was given quite a good answer to use CustomAfterMicrosoftCommonTargets, CustomBeforeMicrosoftCommonTargets. They do work, so I decided not to stop in the middle.
Issue is that I don't want machine-wide tasks. It's not a good idea neither for me (it will affect other builds. sure, this can be handled, but still), nor for my teammates (I don't want to let them put something in system folders... ), nor for build server.
What is needed: solution to be built from scratch out of source control on clean machine with either Visual Studio or MSBuild.
It appeared that Custom*MicrosoftCommonTargets are regular properties.
So, how to specify this property? It works pretty fine when to set it from command line.
That's strange, but it appears that bit of magic present here: property passed as command line parameter to one build is transitively passed to all nested builds!
That's fine for build server. But this won't work with Visual Studio build. And even declaring solution-level property won't help: neither static, nor dynamic properties are transfer to nested builds.
...I have a hacky idea to set environment variable on before solution build and erase it on after. But I don't like it. Any better ideas?
I use a bit different technique then #Spider M9. I want that all projects in solution tree/all subdirectories from current directory use extended build throw Custom*MicrosoftCommonTargets. I don't like to be forced to change every new project to import custom targets/props.
I place special file, let's say msbuild.include, in the root directory and my custom targets loader for every project tries to find it in ., ..\, ..\..\, and so on. msbuild.include contains flags that triggers execution of custom actions. If loader can't find this file it disables loading all custom targets and stoppes. This gives me ability to use my build extensions with projects from work repositories and to not use with opensource projects.
If you are interested in I can publish loader. It's a pretty simple and elegant solution.
For example I can sign any assembly in all projects in all subfolders with my key.
I always set up every project to import a standard .props file. Use the GetDirectoryNameOfFileAbove property function (see MSDN) to find it. Do this as the first line of every project file. Once established, you can redirect from that file to other imports. Another trick is to have that standard import (that would obviously be under version control) import conditionally another .props file only if it exists. This optional file would not be in version control, but is available for any developer to create and modify with their own private/temporary properties or other behavior.
I have a csproj file, being part of two different Visual Studio solutions. The project file should be able to behave slightly different, depending on the solution it will be used from. What I would need, is something usable as a 'Condition' - a property named for example $(SolutionName) - filled in automagically.
At least, this is my idea. I didn't found anything like that.
I also considered to have two small project files importing the common parts. This would prevent editing all these properties from inside Visual Studio, I guess. It would write changes only in the active 'master file', correct?
So, is there any other way to discriminate at project level using solution information?
Turns out there is a property named exactly $(SolutionName). Try this; first set an environment variable as:
> set MSBuildEmitSolution=1
Then build your solution file using MSBuild from the same command line
> MSBuild My.sln
You will find the MSBuild project transformation of your solution file, it will be named My.sln.metaproj.
Just open that in a text editor and you can see the other properties. Examine the "Build" target in this projectd file, you can see that all these properties are passed in to the MSBuild task when it builds your projects, so you should be able to discriminate conditions based on any of them.