I've already overridden the version number in the nuspec through the build steps in TeamCity (Nuget Pack), but I don't know how to override any specific variable - is it only possible with the Command Line Parameters or is it possible to expand it in some way so that a new parameter is possible in the build step (as is with the version parameter)?
If only through the command line, do any have suggestions? I guess a path is needed as with the Package Parameter, but other than that I'm lost.
I think that Properties field is what you're looking for:
According to the docs, it can contain:
Semicolon or new-line separated list of package creation properties.
For example, to make a release build, you define here
Configuration=Release.
I've highlighted the term package creation properties as this is the out-of-the-box mechanism to pass parameters to the NuGet package creation process.
Related
I am looking a way to manage dynamic environment variables in my build arguments.
I am able to make it work if I define values for TARGET_FILE and FLAVOR in the environment variable section in CodeMagic.
But my goal is to have the values specified in my git repository. So I will be able to change it and have a dynamic build.
I was thinking I would be able to set the env var in the pre-build section.
Following is a sample of my pre-build.sh file
# in my case it’s `dev`, `qa` and `prod`
export FLAVOR='qa'
# major and minor part of app version e.g. 1.0
export VERSION_NUMBER='1.0.0'
# this is the entry point of the app e.g. main_dev.dart
export TARGET_FILE="lib/main_$FLAVOR.dart"
My build is still failing because the TARGET_FILE for example is not specified
Target file "--flavor" not found.
Build failed :|
Failed to build for Android
I was wondering if anyone has ever encountered this scenario
As for configuring build from GitHub you can use codemagic.yaml file that allows you to define the configuration for CodeMagic build, including env variables (here is a docs).
Additional notes, just a proposition))
I actually don't know what is going on in your Flavors and env entry points, but quite possible you can actually get rid of both.
For instance, you can use .env file and flutter_config package to pass env specific variables to the native layer, including plist's and Gradle. Also, you can load this .env file into Dart code and use variables from it. On top of this, you can use this package to generate .env file with the terminal command (if you don't want to create any sh scripts))). Alongside with .env file, it can generate Dart class specifically for Dart code. It also can generate files based on global env variables.
In that way all environment specific configuration will be defined once, you won't expose your prod credentials anywhere except build tool and you won't need to copy/paste multiple entry points.
Update 08/05/2020:
Starting from Flutter 1.17 you can use --dart-defines argument instead of environment_config and flutter_config package to define compile-time variables. You can read more about this argument here
I'm trying to bind the file version from my exe file to be used as product version. Following: How can I set the WiX installer version to the current build version?
The problem is that my assembly builds in the format of e.g 2018.0.0.0. The major upgrade requires a version number of max 255, which means that I have to remove the first two numbers from my productVersion variable before setting it to the ProductVersion property. Is there a way to modify the variable through xsl or something else?.
Modifying through a custom action is no alternative since I want the property to be set in the msi file.
Any help in this djungle is appreciated,
<?define productVersion= !(bind.FileVersion.MyExe.Exe) ?>
<Product Id="*"
UpgradeCode="12345678-1234-1234-1234-123456789123"
Name="My Application"
Language ="1033"
Version="$(var.productVersion)"
Manufacturer="My Company" >
If you can't bind/infer from your assembly then you will need to have your build automation pass a wix variable into candle.exe and use that instead of your bind statement.
In a managed code / vsts / tfs environment my typical flow is that the build definition is the source of truth and it increments and sets a buildnumber during the build. A powershell script updates all the AssemblyFileVersion attributes across my AssemblyInfo files based on this and my wixproj (votive/msbuild) does a regex match on this variable to pass it through to candle.
I'm authoring a NuGet package that needs to, on install time, edit an existing file in the project and put the package's version number into that file. I can do the file edits from install.ps1 just fine, but I can't figure out how to get the package version.
The install.ps1 file gets four parameters, one of which is $package. The sum total of documentation on this parameter is:
$package is a reference to the package object.
I'm assuming the version is in this thing somewhere, but I can find no documentation on what this parameter is, what the type is, what the properties are, anything.
I tried using the NuGetPSVariables test package, it just printed out the package name and version as a string, but it wasn't the right format.
Does anyone have a reliable way to get the package version from inside the install.ps1 file that doesn't involve string hacking on the $installPath?
The $package parameter passed to your install.ps1 script will implement the IPackage interface. This interface derives from the IPackageName interface which has a Version property which you can use to get the package version.
I'm trying to make it so that when I run nuget pack it always outputs to the same directory, rather than typing it in every time. The following link suggests that defaults are possible by setting config file key/value pairs.
http://docs.nuget.org/docs/reference/nuget-config-file
However, there doesn't seem to be a clear syntax. I've tried using keys such as:
OutputDirectory
DefaultOutputDirectory
DefaultPackOutputDirectory
None of which worked. Maybe the "DefaultPushSource" is a hard-coded key in the executable? Is it even possible to set default values for pack options using the config file approach?
here is the list of settings that can be defined in the nuget.config: http://docs.nuget.org/docs/reference/nuget-config-settings
There is no nuget.config settings for nuget.exe pack command yet.
#Chad H : There is no way to do this right now. The best way I can recommend is to create an alias for the nuget pack command which has the outputDirectory flag set to whatever path you want your output at :
https://docs.nuget.org/consume/command-line-reference#pack-command
I currently have multiple projects being build using msbuild. I have a small customisation to the build that is handled by a .targets file. One solution is to add the snippet
<Import Project="MyTargets.targets"/>
to each project file. However, ideally I would like to not touch the project files, and be able to pass this information as a parameter to msbuild. That way I could easily control whether I run this customisation from the command line, and I don't have to touch the existing project files.
Is this possible?
You can do that easily with MSBuild 4.0 (check your version by top-level attribute ToolsVersion="4.0"):
There are multiple properties you can use to import your targets before and after Common.targets and or CSharp.targets loaded.
Simplest way is to use 2 sets of self explaining properties.
First set is:
$(CustomBeforeMicrosoftCommonTargets)
$(CustomAfterMicrosoftCommonTargets)
and second one:
$(CustomBeforeMicrosoftCSharpTargets)
$(CustomAfterMicrosoftCSharpTargets)
Property names are pretty self-explained.
Just pass full file name to any of this properties via msbuild.exe
e.g.
msbuild.exe /p:CustomBeforeMicrosoftCSharpTargets=c:\mytargets\custom.targets
You can use other "ImportByWildcard(Before|After)...." properties if you need to import multiple files. But in that case you need to pass more parameters to command-line.
Starting from MSBuild 15.0, the following two files are auto-imported into your build in case they are found on the project path or in any parent folder on the path to the root directory:
Directory.Build.props
Directory.Build.targets
Remark: once the props or targets file is found, MSBuild will stop looking for a parent one.
Also see: https://learn.microsoft.com/en-us/visualstudio/msbuild/customize-your-build
Lets say you have a project file called "Project.msbuild". You would add this conditional import:
<Import Project="$(TargetToImport)" Condition="'$(TargetToImport)' != ''" />
Then pass the name of the target file you want to import as an msbuild property:
msbuild.exe Project.msbuild /p:TargetToImport="TargetFile.Target"
Make sure you use an absolute path to the target file and it works.
Source: Sayed Ibrahim Hashimi - MSBuild how to execute a target after CoreCompile part 2.
msbuild.exe /p:CustomBeforeMicrosoftCSharpTargets="c:\mytargets\custom.targets" /preprocess:out.xml
Use /preprocess[:filepath] to see the result of the imports.
You don't have to modify any csproj or vbproj files.
Of course, it only works where you can set MSBuild Properties.