Our code uses different settings for development and production environments so we were looking at using VS2010's web.config transform capabilities. After hours of trial and error, nothing has worked. We found a Web.config transformation tester and found that what we had been trying was supposed to work (according to this tool.)
We tried testing the transformations using Build, not Publish. Does it only run on Publish or could something else be wrong?
Yes, it only runs on Publish. To test, publish to a local dir. You'll want to publish your application with the correct target environment set.
You can also integrates web config transformations with MS Build.
It seems you don't have to be in Publish mode to generate a transformed Web.config file. There's just a bit more work involved.
Open the Visual Studio Command Prompt and navigate to your working project directory that contains your .csproj file. Enter the following command:
MSBuild project.csproj /t:TransformWebConfig /p:Configuration=Debug
The example above would run the Debug transformation during the build of project.csproj. This will output a Web.config file into the obj\Debug\TransformWebConfig\transformed\ directory, where Debug is whatever Configuration you set in the command above.
Copy this file to replace your root Web.config file, and you're done. You could write a batch script to run both of those items automatically, but for larger projects with many configurations it could become unwieldy.
You might be able to add those command line arguments to the build process inside of Visual Studio, but I'm not sure how - as far as I know for this method to work you would have to build from the command line instead of inside Visual Studio. You can still use Clean inside of Visual Studio to clean out the obj folder but it will only clean the solution configuration mode selected in the IDE. Clean will not revert your edited web.config file, so you may want to back it up before proceeding if you need to.
(Command line arguments found from this MSDN article.)
You don't need run Publish/Build Package in order to test Web.config transformation. There is a cool trick to quickly know the transformation result here. Scroll down until you see a comment about creating TransformConfig project. It works like a charm, note that you can safely ignore 7th step (frankly I don't know how to do that step properly but fortunately we don't need it :)).
Related
I'm trying to create an automated way to build mpir on Windows with Microsoft C++. One required step seems to be to install vsyasm, so my current mini-project is to create an automated way to do that, i.e. something that can be done by a batch file or program without human intervention.
The vsyasm readme suggests three methods:
a. put these files in the MSBUILD customisation directory,
which is typically at:
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\BuildCustomizations
or:
C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\BuildCustomizations
b. put them in a convenient location and set this path in the
'Build Customisations Search Path' in the Visual Studio
'Projects and Solutions|VC++ Project Settings' item in
the 'Tools|Options' menu;
c. put them in a convenient location and set this path in the
'Build Customisation dialogue (discussed later).
The first is blocked by Windows security. Are there any ways around that that don't require manual intervention?
The second and third directly require manual intervention. Are there any automated equivalents, particularly if you want to end up building the project from the command line instead of within the IDE?
Are there any other options I'm missing?
As far as I can tell, there simply is no repeatable way to install vsyasm. There is, however, a repeatable way to build mpir with the command line compiler, and this is the way I recommend doing it: forget about Visual Studio integration, download plain old yasm, rename it to simply yasm.exe, put it somewhere in your path, run vcvarsx86_amd64.bat and:
cd \mpir-2.6.0\win
configure.bat
make.bat
I'm currently using the default build process template in TFS 2013 for my automated builds.
I've configured the OutputLocation parameter to be AsConfigured to get the same folder structure as my Visual Studio solution (there are multiple projects in the solution and I don't want them all to be dropped in the same folder).
The problem is that when the build process tries to run the tests, it looks for any assembly under the bin folder, while my build configuration makes it so that there is only a src folder.
Is there a way to specify looking into the src folder instead? Shouldn't it be the default anyway when using the AsConfigured setting?
Edit: Just to make it clear, there are usually 3 folders generated when running a TFS automated build (src, bin, tst). When using AsConfigured for the output location, there is no bin folder. I tried a suggestion which required changing the Test sources spec setting of the build process, and I get the same problem as before:
There were no matches for the search pattern C:\Builds\8\MyProject\MyBuildDefinition\bin\***test*.dll
What I ended up doing is using a PowerShell script as a post-build event to copy my test assemblies to the bin folder of the build.
There are PowerShell scripts made available for TFS 2013 on CodePlex, and I modified this one slightly to accomodate my needs.
By doing this, I was able to use the default settings for running the tests, and it worked like a charm.
In your build definition, change the value of setting "Test Sources spec" to ***test*.dll (assuming your unit tests assemblies are suffixed with .test.dll)
EDIT: Please use **\*test*.dll;**\*test*.appx
Try to use this file masks: ..\**\*test*.dll
It works for me.
I have "AsConfigured" setting on for X64 platform that places the binaries into src\x64\Release\ (and it used to place them into bin\x64\Release\ without that switch). So, I ended up using ..\..\..\src\**\*test*.dll as my "Test Sources spec".
I am using this extension (https://github.com/ceztko/SolutionConfigurationName) to put solution output all in one folder. It is working splendidly on our development machines. (I modified the source to support VS2012 installation)
We are now trying to run a build using devenv.com, but it seems that the macros are not being evaluated properly --or rather, they are an empty string ""
Does anyone know if devenv.com plays nice with extensions? Or maybe the workflow for a headless build is different such that the extension is not getting triggered? It uses UpdateSolution_Begin to update the variables.
tia
A headless build won't load that extension, and definitely won't go triggering solution events like that.
To be honest, this feels strongly like an XY problem. A solution build results in the MSBuild Configuration property being specified to each individual project, and I can't think of any scenario where you wouldn't simply be able to base a build customization on that property. For the Roslyn codebase itself we direct all OutDirs for all projects by simply having a single msbuild .targets file that defines the output path, and then we include that in all projects. Very clean, and doesn't require VS extensions to be installed, or even VS installed at all in order to do a build.
In the main project of my VS Solution I have a Resources folder with some required external tools. When building and publishing the solution, I get a .\Resources* with all required files there.
So far so good.
However I have to move some files to the parent directory.
My first attempt was do so with the Post Build Events. It works and does move them the correct folder.
Nevertheless in the publish output they still appear in the Resources folder and I need them in the parent one :/
Is there any way to setup the target output path for resources in Visual Studio?
After some research and experimental, I solved my problem.
Still, here's what I learned in the process.
The first attempt was adding the file to the project root and mark it as a resource. After publishing it worked. But having those files in the project root its lame.
Since I needed some *.exe files compiled in another VS solution, added them as a project reference. Gave it a try and it passed the "Publish" test. But still.. not the best way to do it.
After that, with some scripting and a post-build event, I copied the required files to the correct folder. Works.. but after publishing, they don't appear in the package.
However, there is still a possibility with the Mage tool:
http://msdn.microsoft.com/en-us/library/acz3y3te.aspx
This lead to some promissing experiments, however they ended up helping me realize how limited the MS ClickOnce is, so I decided to try other tools.
Here's a good start to follow:
What alternatives are there to ClickOnce?
I had a similar situation once. I found it became more trouble than it was worth to customize output paths and such in Visual Studio, to the extent that I wanted.
I ended up letting Visual Studio do its own thing with regards to file/project structure, and wrote a post-build script to copy everything that was needed into a final, 'publish-ready' directory.
I then set the execution target in Visual Studio to the new location, so I could run/debug as normal, but with the new folder that was organized how I needed it. Careful, I think this is a user project setting; so other developers will need to do this on their machines too, if they so desire.
I do recall changing some output paths and such to make the post-build script more simple. But changing things like that can lead to annoyances when you add new projects to the solution; you might need to configure them to match. It's all a trade-off :)
Two ideas:
Maybe you could move your resources into another project - a project just for resources - and then set their Build Action to Content and Copy To Output to true. Then reference this new project and build the solution. (This may not work as you want, just an idea).
Why not make your resources embedded resources instead. Keep them all within the Resources\ directory and access them programatically?
This may sound like a newbie question - and it is. I'm relatively new to vs, we started using it a few months ago, and I still haven't "mentally" made the change from the command line. So, if you could help me with 2 things:
I create a new project (not a solution). He puts the files in some directory. After putting my code inside it, I click on the little green triangle (Debug, it says), and he compiles it, builds it and runs it. It works ok. Now, sometimes, I have to change only a tiny bit of code and I don't feel like getting the whole VS up just for that. How can I do that Debug thing from the command line, with the assumption I didn't change anything else.
Where do I tell him not to create a "Debug" subdirectory, not to create a HTML Build log, an object file ... and so on, generally, where can I find the settings which will help me to get as little files ... apart from my original source, and the .exe resultant one ?
I have to change only a tiny bit of code and I don't feel like getting the whole VS up just for that. How can I do that Debug thing from the command line, with the assumption I didn't change anything else.
I think what you want here is not debugging but a rebuild of your project.
Where do I tell him not to create a "Debug" subdirectory, not to create a HTML Build log, an object file ... and so on, generally, where can I find the settings which will help me to get as little files ... apart from my original source, and the .exe resultant one ?
The answer to both these questions is to use the command line! You can make VS emit a make file from the loaded project. Use NMAKE to build this make file after you have made your desired modifications. The ".obj" files are created as an intermediate step between compilation and linking phase this is how the C++ compilation model works. Why do insist on not generating them?
You can't really start debugging without starting up Visual Studio, since Visual Studio is the debugger. You can tell VS to rebuild a solution from the command line without firing up the UI if you want to just build it: See MSDN for details.
You can control the creation of the DEBUG and RELEASE directories via the 'intermediate files' option in the project settings. Though you need to create the obj file somewhere in order for the compile to work.