We are using Dynamics CRM 2016 on-premise.
We created a managed solution to transfer our customizations to the production system.
Part of those is a business process flow.
Issue: We changed the BPF in the managed solution: We deleted steps and renamed steps. But those changes are not deployed to the production system.
The deploy log shows no errors. It shows our BPF as "imported". But the "workflow activation" is empty.
We tried deactivating the BPF in the target before importing it. No avail: The BPF in the target remains unchanged. Any ideas?
Related
We’re having the following CI process in our CRM Dev environment:
We have common CRM environment which is used for customizing system. Plus, many development virtual machines (each of them has their own CRM instance installed) for individual developers. We store unpacked CRM solutions inside GIT repository, and we have automated process of packing them (with CRM solution packager), importing and publishing them on developer’s VMs.
Our problem at this moment is that importing single solution (containing all the customizations) packed with Solution Packager takes quite a long time. I was looking for some method to automatically create Dynamics 365 solution containing only “delta” changes and import it into development machines (unfortunately – I could not find any other than creating “delta solutions” directly inside the common CRM environment which does not help in case of our CI flow).
Unfortunately, the environment is CRM 2015 so using solution patching/upgrades is not an option.
Any thoughts? Ideas?
I'm working on a check in policy and while testing it the first time, I got an email from a teammate saying he couldn't commit any files, because when I installed the policy for testing on my machine, his TFS died, because he didn't have the policy DLL installed and registered. It seems that when I registered the policy locally, the TFS server registered it for the whole team, and the other members don't have it yet, so their commits blew up.
But how are you supposed to develop and test a policy if the only way to do this is installing in the global TFS server for everyone? Clearly, the policy code isn't ready for deployment before you ever try to test it, and you can't test it if testing breaks TFS for everyone until you test and deploy it.
What is the way out of this problem? Ideally, I'd like to have a local-only policy, but that doesn't seem to be possible.
Policies are set on a per Team Project basis. There is no local setting for check in policies, they are created against the Team Project and everyone who is using that Team Project will be affected, meaning that you will have to roll out the dll to all users.
Your best solution is to have a test Team Project where you can try out new builds / check-in policies and other bits and pieces in isolation.
Once you are happy with what you have, you can then apply the same items to the main Team Project that your team is working on.
solved - see update below...
I created the activity in a separate workflow activity project
In my SharePoint project I added a reference to the activities project
I also included the activities project's output to the SharePoint package (deploy to GAC)
Next in my SharePoint project I created a pre-deployment msbuild action to copy my activities dll to the workflow manager directories (activities and WFWebRoot\bin).
Of course I also put an "AllowedTypes.xml" in the two relevant directories.
I did not automate restarting the workflow manager backend service. I believe I only need to restart it if the .xml file has changed, right? Or any time my activities.dll changes?
Now my problem is I cannot debug my workflow CodeActivity. The workflow works just fine and attaching to the workflow.servicehost.exe I can debug my workflow in visual studio - it hits breakpoints on any declarative workflow activity. Unfortunately any break point in my custom CodeActivity is not being hit :(
Any idea? Obviously I have SharePoint and Workflow Manager running on the same machine. I'm not sure why deploying the activities dll to GAC is required - and iisreset?! (See this technet article)
UPDATE: Some lessons learned...
Do stop WorkflowServiceBackend before deployment (I'm using the build event).
Start the WorkflowServiceBackend again on post-deployment event.
Otherwise the workflow service may block access to the GAC'ed activities assembly and it will not be replaced. It happened to me. Now as you (should) know any GAC'ed assembly is always prefered over any "local" assembly. And obviously the workflow service used my GAC assembly - do I still need to copy my activities assembly to artifcats and wfwebroot\bin? NO. I deleted my dlls from the workflow manager directories and I was still able to both execute and debug my workflow activities without any hazzle.
We have been facing this issue quite since a long time, and this is repetitive.
Application : Team Foundation Server 2010
What is the Issue: Users report that the build definitions are not visible.
Who observe the issue: Members that are specific to a project report the issue. However, the Project administrators(Default Collections) can access and queue builds without issues.
What is done as a workaround: We restart the TFS server, and reapply account from the Application Tier, after which the builds are visible to respective project Contributors.
Can some one let me know, what would be the issue, root cause, how to fix it?
Please add for any queries.
When manually deploying a simple application from Visual Studio 2012 to BizTalk Server 2013 (i.e. right-click -> deploy) I receive the error:
Error 63 Failed to deploy map "<fully qualified map name>".
Error saving map. Stored procedure returned non-zero result. Check if source and target schemas are present.
This happens when I deploy the entire solution but not when I deploy each project individually.
I have found the link below which describes this error exactly and suggests installing a hot-fix, however this is specific to BizTalk 2010, not 2013. I have tried installing BTS 2013 cumulative update package 1 however this has not fixed the problem.
http://support.microsoft.com/kb/2673264
Any ideas what to try next?
I actually just went through this same deal.
Are you using a dll to reference a schema outside of your project? The issue with mine was that I was using an assembly to reference the schema in my map, but upon deploy that dll was not added to the project as a resource.
Manually add that assembly as a resource to your biztalk project, then redeploy the project with your maps and that should work.
If you are doing this on a VM, I would suggest taking a snapshot and try applying the Hotfix. If it works, I would run with it; if not, I would suggest rolling back the snapshot and raising a call with Microsoft via their Connect website indicating that the Hotfix KB2673264 addresses your specific problem, but does not work with BizTalk Server 2013.
The Microsoft Connect Website for BizTalk can be found at https://connect.microsoft.com/BizTalk.
You might also want to raise this question on the Microsoft MSDN BizTalk Forums: http://social.msdn.microsoft.com/Forums/en-US/home?category=biztalkserver
Add the assembly that contains the dll as a resource assembly in BiztalkApplication1 it worked for me
Verify that all the external assemblies are up to date in the application1 or simmilar common applications
This usually happens if you deploy binaries (msi) to new biztalk environment. This is due to source/target schemas (and any other reference assemblies) are not yet available on new biztalk environment.
You should also consider the script functoid components that are called on the maps.
Sometimes those schemas might be available on other applications. Try deploy those first.
Check your solution/properties, then configuration on the left.
From there you can click checkboxes of what needs to be deployed or not.
Make sure you are deploying the schema projects that the map is using.
(Or deploy the schema project first, then deploy the map project.)
In my case, the error was due to another non-deployed BizTalk project.
To be able to see where the "real" issue was, I used this solution : Greg Sharp blog
It allows me to find out that the project referenced in my current project was not deployed in BizTalk (Dlls was GACed so the build wasn't throw any error).
Check that all dependencies used in your project are GACed AND DEPLOYED in your BizTalk server.