I am using Install Script in Install Shield 2013 on Windows 7, Lang Used C#.
I have a project and it has some features and sub features added to it. Now I want to build a new release using Automation Interface need to add some selective features/ subfeatures to this release so that the original features remains unaltered.
We can pass the New release name and features required in this release using Command Line.
How can I add selective features supplied as command line arguments to my release. Is there any predefined Object/function/Method for this. Please advise.
Need to achieve this in Install Script only.
We can do so by using IncludeInBuild() property of ISWiFeature. It alters the default IncludeInBuild value of a feature.
To make it temp store the current values of the features to be altered in a list , then build a new release. After making new release, once again assign the value stored in list to the altered features.
Related
I am following along the examples in the vulkano-rs website and at the section where it says to create an AutoCommandBufferBuilder, it says to use AutoCommandBufferBuilder::new() to create it.
However, in the latest version of vulkano-rs - 0.23.0 - this method is missing.
If I downgrade to version 0.22.0, the method exists.
So, how do I create an AutoCommandBuffer in the latest version of vulkano-rs?
From vulkano-rs/vulkano#1527:
AutoCommandBufferBuilder::new renamed to AutoCommandBufferBuilder::primary/secondary. For primary form there is a new additional 3rd parameter. Use CommandBufferUsage::MultipleSubmit for this parameter to fulfill the same behavior you previously had with old new constructor.
In my release pipeline for a dotnet core project, I want to increment the assembly version automatically so I don't need to update it manually each time. This is so my Nuget version is increased every time.
At the moment I'm using the dotnet pack command and adding the build number at the end using the "Automated Package Versioning" set to "Use Environment Variable: Build.BuildNumber". Then I set the "Option > Build Number Format" to "1.0.$(BuildID)". First, I tried setting the attribute of the .csproj file to 1.0.$(BuildID), but the pipeline did not pick that up.
The problem is that I have to edit my build pipeline every time I want to adjust my major or minor semver version. Yet with the teams, we agreed not to put build pipeline config in source control (yaml files). Is there a way we can put a part of the build pipeline in a yaml file so that we can override parts of the configuration?
For example: I could set the "Build Number Format" to "$(Major).$(Minor).$(BuildID)" and then the partial yaml could override the Major and Minor variables.
How to set up automatic nuget version increments
If you want to automatic nuget version increments, you could use the BuildNumber $(Rev:r) instead of $(BuildID):
Run (build) number:
$(Rev:r)
2 (The third run on this day will be 3, and so on.)
Use $(Rev:r) to ensure that every completed build has a unique name.
When a build is completed, if nothing else in the build number has
changed, the Rev integer value is incremented by one.
If you want to show prefix zeros in the number, you can add additional
'r' characters. For example, specify $(Rev:rr) if you want the Rev
number to begin with 01, 02, and so on.
So, you could set the Build Number Format to $(Major).$(Minor)$(Rev:.r).
Hope this helps.
I've created a powershell script that updates a Pipeline Variable during a Release Pipeline. It takes the custom variable and updates it with a new version using semantic versioning with every run.
I've tried to add this custom variable as the Release Pipeline but keeps on giving me an error "Names of releases from this pipeline will not be unique. Use pre-defined variables to generate unique release names."
I've tried setting the variable to "Settable at Release" and putting the scope to "Release"
Does anybody perhaps know if there is a way to let the release pipeline know this is a dynamic variable that changes?
The only other option is to add the revision number to it $(versionnumber)$(rev:.r)
use Custom Pipeline Variable for Release Name
For this issue ,I think it not feasible to achieve it. Release name must be a unique name,
the $(rev:r) token can ensure that every completed build/release has a unique name because it's adding a incremental number for each release. When a build/release is completed, if nothing else in the number has changed, the Rev integer value is incremented by one. So, basically we cannot achieve that without using $(rev:r), unless you can defined a token which has the same function with $(rev:r).
In addition,you can also use $(Build.BuildNumber) or $(Release.ReleaseId) which are also unique.
For the similar issue,please refer to this case .
I want to change release names like V.1.0.00 for manual release in Continuous Delivery of Azure DevOps but i can't able to delete or change the naming without this $(rev:r), how can I use a custom name?
Default Name: Release- $(rev:r)
Required Name: V.1.0.0
In the build Pipeline.
You can customize how your pipeline runs are named/numbered. Ref : https://learn.microsoft.com/en-us/azure/devops/pipelines/process/run-number?view=azure-devops&tabs=yaml
In YAML, this property is called name.
Use variables to set your major version, minor version etc and generate the patch version using counter Ref : https://learn.microsoft.com/en-us/azure/devops/pipelines/process/expressions?view=azure-devops#counter.
for your case you can set
major : V.1
minor : 0
patch : $[counter(format('{0}.{1}', variables['major'], variables['minor']), 1)]
and set the name like
name: $(major_version).$(minor_version).$(patch_version)
Release pipeline
Refer to $(Build.BuildNumber) which will ref to the buildpipeline custom name/number set in the build pipeline. You can change this naming scheme by editing the release name format mask. In the Options tab of a release pipeline, edit the Release name format property in the General page. Ref : https://learn.microsoft.com/en-us/azure/devops/pipelines/release/?view=azure-devops#how-do-i-manage-the-names-for-new-releases.
You can change the naming scheme by editing the release name format mask.
When specifying the format mask, you can use the pre-defined variables mentioned in this official document or custom variable -- the value of a global configuration property defined in the release pipeline.
But for your issue ,as far as I know, no pre-defined variables can be displayed like V1.0.0 as release name.
You can't. release name must be a unique name, therefore Azure DevOps requires you to put $(rev:r) in the name, because it's adding a incremental number for each release.
Another option is to use $(Build.BuildNumber) or $(Release.ReleaseId) that are also unique but is not will solve your issue.
(I'm using InstallShield2012 V.18)
In setup.rul I defined a function per prototype declaration, included the file with the function definition and compiled it successfully (InstallShield compile).
Now I'd like to test this function (only).
I don't want to run the whole installation, not even test (Ctrl-T) because I want to avoid a complete re-build which takes too long time to do it often.
Is there a way to test only the custom function in InstallShield or per command line?
Not really although I can give you some tips.
Create a dummy feature with a release flag of DEVONLY.
Create a dummy component for that feature.
Create a ProductConfiguration that builds a single MSI with no EXE and a release flag of DEVONLY.
Building this production configuration will be very fast. A couple seconds on my laptop with an SSD. You can selectivly include other features through the use of release flags if you need certain components in order to setup the test environment for your CA.
Another strategy is to develop your CA in a test harness project and then transplant the code into your real installer when you know it all works.
Christopher, thanks for this fast reply. I have to put my answer here because commenting was restricted, because too long.
I also thought about using such a workaround but first wanted to avoid it if possible.
But ok, now I tried these steps, 1 and 2 no problem, but 3: InstallShield didn't allow me to configure a Product Configuration without Setup.exe in my .ism file (although we have IS2012 Pro).
Then I tried to do it in a Basic MSI Project (is that what you meant?), which really builds in very short time. And now I can see my scripting during Test Release, yeah :-)
To "transplant" my script now to the main ism I'm missing an export function for .rul files as it exists for custom actions, but there is only a import. So I will have to copy-paste while switching between ism files, but never mind.