Is there a way to use the product version number as a variable when building an path for where the exe gets dumped or for other scenarios, etc.
That way I can set the variable once and just have it automatically be updated everywhere.
(eventually, I want to pass in the version number, but thats down the road.)
Thanks
I tried lots of things but there seems to be no way to use a variable product version string (there's a number of threads on the net as well that come to this conclusion). Moreover in our project we also use the version string in the shortcut names, the setup file name etc and found no way to store this in a single place. We found a very manageable solution though via automation. Here's a sample that updates version number and filename using VBScript, but you can also use C# for instance.
Set ISWIProject = CreateObject("IswiAuto19.ISWiProject")
ISWIProject.OpenProject "Our.ism"
ISWIProject.ProductVersion = "4.0.2.0"
ISWIProject.ISWiProductConfigs.Item("Release").SetupFileName = "App_4.0.2.0_Setup"
When building with IsCmdBld.exe you can specify the build location with the -b option. The bummer of this is that it will actually change the ism. It always annoys me that a build will change a source controlled file.
It's also trivial to pass in the product version on the commandline with -y (oddly - this doesn't change the .ism file)
I don't think you can specify a property such as [ProductVersion] in the release location, nor was I able to create a path variable and use that as the release location.
Related
As the question says, I would like to know the best practice of how we preserve Version of the software while we are shipping in a form of Tarball.
I already use version in Archive file name, however it is lost when user unpacks it. Over some time, I won't even know which version of software user is operating on.
Looking for some sort of method such as MANIFEST.MF that java uses but didn't find anything with standard practice about it.
I can add to the build script to include that file and add version in the content every time I run the build script. But is there a practice already existing that I can use instead?
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
I'm using LLBL Gen Pro 3.5 command line (CLIRefresher and CLIGenerator) to create the solutions.
It automatically creates a AssemblyInfo.cs which contains this code:
AssemblyVersion("1.0")
I want to set it to another version while building the project. For example:
AssemblyVersion("2.1.0.234")
Question1: How can I tell LLBL to create the project with this version?
Question2: If it is not possible, how can I tell LLBL NOT to create this file, so I can add this file later using MSBuild?
A1: you can, through a custom template for assemblyinfo. It's bound in the file SD.TemplateBindings.SharedTemplates.templatebindings in the folder \Frameworks\LLBLGen Pro\Templates
You can define a new binding by creating a new templatebindings file, store it in the folder you define as 'AdditionalTemplates' folder in the project properties, and you should give that templatebindings folder a higher precedence than the one you're 'overriding' (or move it up in tab 2 on the code generator config dialog). See the SDK docs for details.
A2: It is possible, see A1. But here's the thing: this file is written once (done in the preset you're using to generate code). If the file exists the next time you generate code, it's left alone. This means that if you change it, e.g. by giving it a different version number, it won't be overwritten.
So while you could change the template easily, in this case it's not needed: you can do whatever you want with the file after it's been generated, it's not generated again.
(ps: please ask questions about LLBLGen Pro on our forums at http://www.llblgen.com/tinyforum, as we don't monitor stackoverflow that regularly. Thanks)
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've created an installer Exe file with InstallAnywhere. This Exe installs some files. This Exe also shows info about current version number. Later I want to change some of the installed files via patches. current version number gets changed after applying patches. How can I show this new version number without re-creating new Exe? Is it possible to read version number from a text file in InstallAnywhere?
If you are using InstallAnywhere 2011 then yes. Refer IA2011UserGuide.pdf under the section 'Setting Project Version at Build Time' for more details.
it sounds like the "version" you are asking about is an attribute of your program, not the launcher that you build with IA.
If that's correct, you could make your program read the version string from registry or a text file at startup, and make every patch update that reg string or file artifact as part of its deployable.
One way to get this for free is to have your production environment stamp the jar files' manifest entries with the current source-control build/commit number. That way you always have a way to compare two builds' artifacts versions even if you forgot to bump them manually in the user-presentable-version-string. :)