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
Related
I have a solution where there is a dependency on 7zip's sfx. Out of desire to keep the entire solution (plus the sfx) managed and coordinated, I want to create a new project to house all the source files that is used by sfx, and when building, execute a command line that tells 7zip to build a sfx from the source files, and place into the output so that it can be then referenced by actual Visual Studio projects within the same solution.
I think I can figure the command line by using Build events and providing the appropriate macros to ensure that the 7zip's output is placed into the target folder with appropriate name so that it can be then correctly referenced by other VS projects. But what I am not sure about is what Visual Studio project I need to use or steps to take to tell Visual Studio that there isn't going to be any code to be compiled in this project and it just has to execute this script I give it.
The closest thing I can come up with is VS's Make project but I don't know if that is the right thing since this has nothing to do with Make at all.
So, what is the Visual Studio project template I need to use? If empty, then what configuration do I need to perform so that it won't try and look for some code files to compile but instead just execute scripts as part of the solution's build?
For now, it seems that using C++ Makefile Project works. I had to make few configurations:
1) I had to specify the project's "Configuration Type" as "Utility"
2) I used Pre-Build event and provided a command to invoke a batch file included in the project. The batch file then takes care of everything.
3) Normally, non C++ files are not considered for determining whether build is needed or if it's already up to date. To ensure that a new build is perform if the batch file or other key files are edited, I set the file's "File Type" to "MakeFile". Even though it isn't actually a Make file, it ensures that any edits made to the file will cause a new build.
The downsides I've found so far are:
1) C++ uses "Filters", not folders. Therefore, keeping the files in same directory structure is a big PITA. One can "include" files and get a one-to-one mapping between "Filters" and the actual directory structure on disk but it's annoying and tedious. Wish it was a C# project
2) I'm a bit wary about how it will detect new files or other changes for files that I didn't explicitly set to "MakeFile". I expect the source to be stable but I worry that when I realize I need a new file and add it, I might forget and not notice that the build is not correctly including the new file.
I'm not sure if this is the best method but this works for my purpose - having a project to manage external tools as part of bigger build process.
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.
When I use Visual Studio 2010 to debug a crash dump file (native code), it attempts to load C/C++ source files from the original build folder (and it gives the message "The source file is different from when the module was built. Would you like the debugger to use it anyway?"). The message is correct; the file is not the correct version.
What I would like VS2010 to do is to check out the source file using source server. If the file does not currently exist in its original build location, VS2010 will correctly use source server and retrieve the appropriate revision of the file (from Subversion). In order to force it to check out the correct revision, I have to physically delete the file from the original build location.
As a side note, VS2005 works as desired (well ... as I desire, perhaps not as others desire). VS2005 will always check out the correct revision from source control regardless of whether a copy of the file exists in the original build folder.
I believe the question comes down to one of the following:
Is there some kind of setting available that will change VS2010's precedence for finding source files?
Alternatively, is it possible to make VS2010 offer a choice/option to check out the source file in question? (Currently the only option I see in this situation is to browse for it.)
Or is it possible to completely exclude a specific path (folder) from the search?
I have the same problem with VS2010 and made an attempt to figure it out. I monitored devenv.exe with procmon but didn't see anything out of the order with the files & registry keys it was accessing. Pretty much the same information you see in the error report when VS2010 can't find the source. My solution is to use VS2005 as it works fine. I did see some correspondence on MSDN about a similar (if not the same) bug and they claimed it would be fixed in the final release of 2012. I believe I have that final release of 2012 and it has the same problem.
Here's a maybe slightly complicated solution
1) Create a script that will download and replace the pdb file (a .bat, a python script, whatever)
2) Create a new External Tool within VS2010 (Tools -> External Tools -> Add)
3) Point the tool to your script and pass any project-specific stuff to it as arguments
4) Create a post-build or pre-build step in your project that will call your new External Tool (project properties -> Build Events -> whatever)
This is a lot of work, but at least it will fully integrate it into your building process.
Note: Sometimes I've noticed that my post-build steps won't run unless I've compiled at least on cpp file. I usually press F7 and build some source and then build fully, to make sure everything works as expected.
You can change the local source directory to a different name when you are debugging crash dump file.
Or you can change the build directory to a different path with your local directory.
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 :)).
I've been looking at various different ways of making an installer (see How to create a robust, minimal installer for Windows? for details), and I've run into the same thing in a couple of them (WiX and the visual studio installer creator); there doesn't seem to be a way to say "When you build the installer, include every file matching c:\somefolder\*.xml".
I can go and select *.xml and add all the files that match to the project at once, but then if I add another .xml file to my program later, I'd need to go and add that to the installer myself.
Is this a core limitation of windows installer, that I can't just tell it "sort all the XML files in this folder out and don't bother me about them"?
WiX toolset contains an utility called Heat. It can generate the WiX authoring for you based on your needs. The output can be further transformed by XSL templates (-t switch).
Hope this helps.
InstallShield also has this ( see Dynamic File Linking ) but honestly I don't like this pattern in general. It's non-deterministic in nature. I speak from 14 years of experience when I say that if a file is added or removed from my application I want to explicitly add it or remove it from my applications installer. Any magic to automate this has always bitten me in that it takes what should have been a build time error and turns it into a run time error.
My best practice is to write some automation that compares what was available to be consume against what was consumed by the installer. The two lists must match 100% or otherwise fail the build. When the build fails you must choose to either add the file to the installer or cease to archive the file to the directory. With the right tooling, it's trivial to add a file to the installer and the result is 100% accuracy of developer intent being applied to the installer.