I have a system with 8 options to deploy and manage all these .config files are causing problems for the team
So I found a Jenkins plugin for installshield. But i don't know how change the product version and product code using jenkins.
In VisualStudio, I change this options in "ProjectInstall > GeneralInformation > Product Version.
What I want to know is:
How change these information by code (jenkins configuration or Nant, or something else)
I'm using "VisualStudio 2013" and "InstallShield Limited Edition for VisualStudio 2013"
I've never used the IS plugin for Jenkins but it's probably just a wrapper for ISCmdBld.exe. If so, it probably exposes the -y and -z arguments (bottom of page) for overriding the ProductVersion and other named properties.
That said, I haven't called IsCmdBld.exe in years. InstallShield has nice MSBuild support which means you can do all of this in MSBuild and just build the .SLN like any other Visual Studio project.
Related
I have a Visual Studio Solution with multiple projects. Few of them are of Visual studio 2017 and few are of Visual studio 2013. The difference is because of the use cases of the projects. Visual studio has the option to select toolset for each project. Now I need to create build through Jenkins using MSBuild. How can I set toolset for projects in MSBuild?
How to Use different versions of MSBuild for same solution C++
First, please make sure that VS2013 and VS2017 are installed in your local agent.
The Platform Toolset from VS IDE is stored in xxx.vcxproj file. It is stores as PlatformToolset xml node.
Like <PlatformToolset>v141</PlatformToolset>
v142 means VS2019, v141 means VS2017, v140 means VS2015, v120 means VS2013
So for your situation, you can just change the PlatformToolset.
Solution
So you can use -p:PlatformToolset=xxx in msbuild command line to specify a specific toolset version to build a project.
Note: this does not permanently change the value in xxx.vcxproj, but uses this specific value when building the project.
1) If you want to build the whole solution,
if you want to use the value in the whole solution(every project uses this toolset), use this:
msbuild xxx.sln -t:build -p:PlatformToolset=xxx
Or if you want to use different toolset for different projects in msbuild command line:
-- change PlatformToolset in every xxx.vsxproj file directly as you want and then build your solution
-- use msbuild script to combine all the projects of your solution and then build this script directly to get what you want. See my answer and change to use <Properties>PlatformToolset=xxx</Properties>.
2) If you want to build the project, you can overwrite the PlatformToolset in command line to specify it.
msbuild xxx.vcxproj -t:build -p:PlatformToolset=xxx
I have installed TFS 2018 Community and was trying to publish a project to plesk domain using one of the publish profiles in the arguments of msdeploy task as shown in the picture below but it only build the project but did not publish it like I thought it would
Generally if you can run the msbuild command successfully with the arguments on local VS, then it should be also available in TFS.
So, please check below things to narrow down the issue:
Just make sure you have the same components installed and configured
on your build agent machine.
Make sure you have the correct configuration for your build
definition.
Based on your screenshot above, just try to set the correct buildPlatform and buildConfiguration (consistent with your project settings in VS).
Also verify that if you have checked in the PublishProfiles, and check the first Get sources step, make sure the system can get the sources and PublishProfiles during the build process.
This article for your reference : TFS 2015: deploy website to IIS without installing extra add-ons to TFS
UPDATE:
In order to use Publish Profiles on the build server, you have to have some of Visual Studio's prerequisites. Make sure you have installed the full version of Visual Studio on the build agent machine.
Besides, you can try with below arguments (Just change the PackageLocation value accordingly) :
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\"
Referecne: Working with Web Deploy and Release Management for the deployment.
I'm new to using jenkins.I am working on C# project and using jenkins for continuous build and release. I completed creating builds for my project and got the .exe and dll files. But i need to repackage it(create a msi) before deploying to servers. So can anyone give a stepwise information for rePackaging and tool to be used with jenkins for packaging. I want to automate this process in jenkins CI AND CD.
Repackaging implies you have a third party installer that you want to reverse engineer into a new/better MSI. You are just packaging not repackaging.
This is a two part question:
Author an MSI. I recommend using WiX and IsWiX starting with this tutorial.
Build it using Jenkins. WiX supports MSBuild and Jenkins has a MSBuild PlugIn. Standard stuff except not that the .WIXPROJ created by IsWiX templates expects you to pass the MSBuild Property MSIProductVersion. The correct format for this property is 0-255.0-255.0-65535. You can tack on a fourth field if you would like but it will be ignored. The IsWiX project templates are set up for Major Upgrades by default so make sure one of these 3 fields is incremeented with each release. ( 1.0.0, 1.0.1, 1.1.0, 1.1.1, 2.0.0 )
This is more of a packaging issue than a Jenkins issue.
Take a look at WIX Toolset. I used it successfully in the past with various projects. Integration with Jenkins should be easy. There are 2 options I'm aware of:
After installing the WIX toolset, add a new WIX project to your Visual Studio solution. Once configured, commit the new project to your source code repository. Then developers can build .MSI packages on their own development workstation. Assuming you use MSBuild in Jenkins to build your C# project, the new project will "just build" and create .MSI package (remember to install WIX on your Jenkins build server). This is the recommended option.
Use WIX's command line utilities to generate MSI in a Jenkins batch step. This is more cumbersome and difficult to debug.
Not too sure if what I'm asking here is possible, or if it requires an upgrade. My problem is that I have a local install of TFS 2013 (that is, on-premises), and all dev machines have now upgraded to VS2015. However, when using new features (such as $"test {teststring}"), we get build errors.
The build machine has both VS2013 and VS2015 installed, and is using the default build template (TfvcTemplate.12.xaml). Looking at the "Run MSBuild" task inside the build workflow, there doesn't seem to be any way to point it to one MSBuild or another.
Is it possible to hint to the build to use the later version of VS / MSBuild and, if so, how?
Try adding /tv:14 to the msbuild commandline arguments in your build template, if that doesn't work, edit the xaml file for your build process template and override the "ToolPath" property of the "Run MsBuild for Project" task. Or make that field configurable through further customization of the build template.
Set that path to C:\Program Files (x86)\MSBuild\14.0\Bin (or your equivalend location in case your machine uses alternate default directory names).
With TFS 2010 build controllers/agents there is the option to set a version control path to custom assemblies that will be available on all build agents. The documentation states that this works for custom workflow activities as well as custom MSBuild tasks (about in the middle of the page):
http://msdn.microsoft.com/en-us/library/ee330987.aspx
Does someone know how this feature can be used for custom MSBuild tasks? I checked into version control an assembly with a custom task and set the option on our build controller to the correct version control path. But I don't know where the assembly will be on the build agent and how I can reference it from within my MSBuild targets file (i.e., UsingTask).
I even searched for the assembly on the build agent but could not find it...
Any help is very much appreciated!
Here's the answer: the contents of the version control path is stored on the build agent in this folder:
C:\Documents and Settings\<user>\Local Settings\Temp\BuildAgent\<num>\
where <user> is the account that runs the build service, and <num> is the number of your build agent.
I have no clue why it was not there at first and what caused the build agent to finally fetch it from source control. Maybe just some patience is required if the version control path is changed or its contents gets updated?
It's possible, but the simpler solution is to just check your custom MSBuild tasks into a shared location in version control, then map that location into the source configuration for your build. That will also make it easier to use the MSBuild tasks for both desktop and server builds.
I use $(Temp)\BuildAgent\$(BuildAgentID) in TFS 2012. Note that in TFS 2010 it was slightly different. Don't expect this to be stable for future releases.