I am facing an issue with my custom workflow activity when I try to update it. Once I do a change on the logic the update is done normally, but when I add new input parameters the changes are not reflected.
Changing the assembly version I am no longer able to update the assembly on CRM.
You are right that you have to change the assembly version to be able to see the new parameters you have added
The assembly with the increased (major/minor) version number should be
registered as a new assembly in CRM (instead of as the same one, as it seems you are trying to do).
In the words of Microsoft: Upgrade a custom workflow activity
Make necessary changes in the underlying code of the custom workflow activity.
Change the values for <major_version> and/or <minor_version> in the assembly information of the custom workflow activity, and
compile it. For example, change the value of your assembly from
“1.0.0.0” to “2.0.0.0”.
Register the upgraded custom workflow activity as a new assembly. Make sure that the new assembly has the same Name, PublicKeyToken,
and Culture as the existing assembly to be considered as a different
version of the same assembly.
After you upgrade the custom workflow activity, existing running
process instances that are using the custom workflow activity will
continue to use the older version of the custom workflow activity
assembly. This ensures that your existing running process instances do
not break. If you want the process to use the new version of the
custom workflow activity, you must modify the process definition to
use the new version. Dynamics 365 displays all the <major_version>
and <minor_version> combinations for an assembly in a drop-down list
for you to select from.
I've run into the same issue. If I don't want multiple assemblies (as #Henrik describes) I follow these steps:
Settings > Customizations > Customize the System
Plugin Assemblies
Select my custom assembly
Select my custom workflow step affected by the upgrade
Show all Dependencies
Deactivate all dependent workflows
Remove the custom workflow step from every dependent workflow (take lots of screenshots)
Use Plugin Registration Tool to unregister the custom workflow step
Use Plugin Registration Tool to update workflow assembly
Update all workflows to use the new custom workflow step, referring to your screenshots! :)
Activate all workflows
This forces all processes (workflows) to use the latest version of the assembly.
The same sequence of steps is required if you're removing custom workflow input arguments or adding output arguments
Hopefully you don't have too many affected workflows.
Related
I'm building nuget in TeamCity and would like to append suffix "-pre" to version number when build is triggered by a checkin. And when build is triggered manually, I'd like to be able to provide a checkbox if this build should be a preview release or production-worthy.
I've got a Configuration Parameter created like that:
In this case I always have -pre added to the version number, even if I trigger the build manually and don't check the checkbox.
If I remove the value -pre from the default value of the parameter, then checkbox prompt works as expected. But when my build is triggered via a check-in, the system does not give me -pre suffix and I end up with a production release which should only be created manually.
Any way to implement what I need?
Alternatively I only want to publish nugets only on a manual trigger of the build and don't really care about pre-releases, but I can't seem to find any way to check if the build was triggered manually or via a check-in.
The first part is relatively easy, using a step to check the value of the checkbox and set a parameter based on it - Here I've used powershell but this could be done in bash (I've assumed powershell as you're producing nuget packages)
Note that I have reversed your logic a bit, but it produces the outcome you desire.
Define two varibles
Setup the checkbox
Setup two build steps
In the first step, test the parameter and use it to set another parameter
In the second step I'm proving the value has been set correctly
You should be able to use %ReleaseSuffix% when you need it.
Regarding your second requirement, I'm again going to make an assumption that you only want to publish a nuget package based on it being a Release build rather than a Pre-Release (if I've assumed this incorrectly let me know)
Conditional build steps based on a parameter value are something I've been tracking for a while now on YouTrack. This has been requested since 2011, but has still not made it in as a feature. I made this comment back in 2014 as a work around, but don't have the Java skills (you might) - My comment on YouTrack Issue
There is an alternative way to get this working, that might require some reworking of your build configurations.
If your "Publish NuGet" step is not triggered by anything (assumming it's triggered by the previous build finishing) then you could have a build step that
Checks the %ReleaseSuffix% parameter
Calls the REST API to trigger the build to publish the NuGet
It would potentially look something like this - just ensure you replace the highlighted bits
TeamCity Documentation
Hope this helps
Although the accepted answer here is very good, it does have a flaw; you will not be able to use the Assembly Info Patcher build feature, as this executes before the first step. Unless you wish to chain your builds together, setting the version in the first and using that in the second (yuck).
I have managed to find a solution which should give you the same results by tinkering with the parameters, setting them as follows:
The reason for using the "EmptyString" parameter is because without it, checked value defaults to "true".
I have tested this with manual triggers (release & prerelease) and VCS triggers (prerelease only), all functioning as expected on TeamCity v9.0.3 (build 32334).
I'd like to show the serial number in the CustomerInfo form (which was captured from the first install and installed in the registry) within the second, third, etc installs when the upgrade is simply a minor version change (or patch). Is this something that can be done within VS deployment project and/or WIX via a custom action (I have a C++ method to fetch the SerialNumber from the registry), MSI config (thru editing a table(s) via say Orca), or otherwise
Regards
Travis
Personally I always do PerMachine installs and don't bother to show the customer information dialog. If an application wants to have licensing it's best to do it in the application on first run.
If you really want to do it in the MSI, you've got a lot of work ahead of you. MSI doesn't persist properties across transactions so you'll have to do it yourself. See:
The WiX toolset's "Remember Property" pattern
I have an open source project called IsWiX. It includes a Visual Studio project template that creates an installer project framework. Part of that framework shows how to insert a custom dialog and then authors a component to handle the remember property for the control on that dialog. You can find the source here.
I'll skip the WiX part that Chris covered.
To do this in a VS project you're supposed to use the Customer Information dialog, added from the list of extra canned dialogs, and use the SerialNumberTemplate stuff. That sets the ProductID property which is the way you're supposed to do serial numbers. So then you could create a registry item in the Visual Studio IDE that has the value [ProductID] to save it somewhere personal. The "official" way to get hold of it for an installed product is MsiGetProductInfo() or equivalent passing the ProductCode and asking for "ProductID" as documented here:
http://msdn.microsoft.com/en-us/library/aa370130(v=vs.85).aspx
To summarize, if the package uses the official PIDKEY /ProductID mechanism (like VS and maybe WiX) you don't need to save it yourself and you can get it via MsiGetProductInfo() or a scipt/managed code equivalent.
If you want to show that previous SerialNumber in a VS setup in the standard customer information form on an upgrade, I don't believe you can do that. There's no mechanism for getting into those forms. If you save the SerialNumber privately, you could try a registry search for your saved serialnumber and store it in the PIDKEY property to see if it shows up there, that might work because the PIDKEY property is the source for that value.
Within my teambuild we use custom build process activities, which are deployed at
\BuildProcessTemplates\CustomAssemblies\MyActivities.dll
The build controller is configured to load the assemblies from that path.
If I checkin new assemblies, then the teambuild does not load the new assemblies automatically, but uses the old ones. In fact the latest build process template seems to be used, because I get the error:
"TF215097: An error occurred while initializing a build for build definition <myTemplate> Cannot create unknown type <any new type>"
If I restart the build controller services, then the latest assemblies are considered.
How can I get teambuild to load automatically the latest assemblies, without being forced to restart the controller?
Finally figured this out. Been driving me nuts for months. Even if your binaries are technically different (i.e. binary differences), it looks like agents only get refreshed if the file version is different.
So more specifically, in my version of "MyActivities.dll", I had to increment the following two lines in my AssemblyInfo.cs (old version string was 1.0.0.0):
[assembly: AssemblyVersion("1.0.0.1")]
[assembly: AssemblyFileVersion("1.0.0.1")]
Once I did that, I did a normal build of the assembly, then checked in the new binaries. Agents were refreshed with the new versions within minutes! :D
Other (less awesome) options if you can't update the version for some reason:
Check in a dummy file to the same dir. If any files are added/removed from the CustomAssemblies dir, it forces a refresh for all files
Change the "Version control path to custom assemblies:" value to some dummy value (doesn't matter where), apply the new value, then change back to the original directory. Any time the path changes, that forces a refresh for all files
The "Best" solution is to just update the file/assembly version, though.
Try to install MyActivities.dll into the GAC. I have all my custom assemblies in GAC and I didn't noticed any issues.
Dozens of Q&A entries (all but one in stackoverflow!) that I found got close to this question, but didn't teach me what I needed. I have what should be a nearly simple installation: a Windows service and an associated tray icon application. They install fine with the standard VS Setup project. After the files are installed, I need to present a dialog to the user to set some parameters in the service's exe.config file. In that dialog, the user should be able to abort the installation. I've tried two approaches to the Custom Action process and ran into a wall with each when it comes to making the installation roll back.
Approach 1: An exe for the Custom Action, run at Commit time.
This sort-of works. The application returns a non-zero exit code and the installation rollback occurs. What I don't like is that:
When the app exits (after the user selects to Cancel), the installation displays an error message saying that there was a problem with the installation and the user should contact the vendor. Since that's not the case, I'd prefer a more correct message ("Installation canceled by user") or no message at all.
Both of the project outputs (the service and the tray app) have to be listed under all four Custom Action sections or my dialog won't appear. Instead, an error appears about a missing InstallState file and the installation always fails. Intuitively, this seems wrong.
Approach 2: An Installer as the Custom Action, run at Install or Commit time.
This is cleaner to me (only the one item listed in the Custom Actions), but getting the process to roll back is worse than Approach 1. It seems that I have to throw an exception in the overridden method (Install/Commit), which then gives me several error dialogs before the rollback occurs, and then the rollback doesn't always uninstall the service.
What is the cleanest way to make this work without going to WiX or similar options?
The simple answer is don't use VS Installer Classes. They have a number of fundamental design flaws. I suggest you look at Windows Installer XML's ( WiX ) Deployment Tools Foundation ( DTF ) instead. DTF is a far superior hosting model / interop library for your managed code and outputs DLL's that are compatible ( from an MSI perspective ) with C/C++ custom actions. They can be consumed as Custom Actions by any MSI authoring tool, not just WiX installers.
Deployment Tools Foundation joins the WiX toolset.
Deployment Tools Foundation (DTF) Managed Custom Actions
I recommend this approach:
create a custom installation dialog which asks the user about your options
use the installer properties set by this dialog to modify your service configuration file (you can use a custom action or the XML support of another setup authoring tool)
This way the information is gathered before the install and the user can also abort the install without problems.
This approach is not supported by Visual Studio, but it can be done with free or commercial setup authoring tools.
If you want to stick with a custom action, you can try this:
make sure your custom action is deferred and doesn't run during commit (commit means that the installation was performed and there's no rollback)
use a Win32 DLL to show your custom dialog; this way you can return ERROR_INSTALL_USEREXIT (1602) so a friendlier user exit dialog is shown instead of the fatal error dialog
What is the correct way to display UI during a custom installer action?
I would like my UI to be modal on the install dialog, or alternatively, I'd like a way to display text/progress from my custom action in the installer dislog.
The installer is a VS2005 setup project and the custom action is a C# Installer-derived class.
Displaying any kind of non-standard UI would require changes to the UI handler object. This isn't trivial, and the implementation depends on the toolkit you use to author your MSIs: I'm not sure it's even possible with VS setup projects.
Displaying simple status/progress messages and logging to the MSI log isn't too hard to do from a custom action, though, at least not using the Windows Installer XML (WiX) toolset, which is what I use myself for this purpose.
When authoring your custom actions with WiX, you get access to the active installer session through the Microsoft.Deployment.WindowsInstaller.Session object, which has 'Log' (writes a message to the log, if logging is enabled) and 'Message' (performs any enabled logging operations and defers execution to the UI handler object associated with the engine) functions, amongst many other goodies.
If you're currently already creating your custom actions in C#, you may be able to find something similar in your current environment (I've never worked with VS.net installer projects, so I'm not exactly sure how they work -- I'm quite surprised actually that these allow you to create managed custom actions...). Otherwise, I'd definitely recommend looking into WiX for custom actions: these work with any MSI authoring environment, and are quite flexible.