We are in the process of testing an upgrade from our current crm 2011 system to 2016. All our plugins appear to be working as expected without recompilation. All of them have been registered and stored against the database.Both the plugin and workflow assembly, reference a custom library which was built with CRM 2011 sdk references. This library has been deployed to the crm 2016 server. When we run a workflow that executes a custom activity in one of the steps we get the following error:
Could not load file or assembly 'Microsoft.Crm.Workflow,
Version=5.0.0.0' or one of its dependencies. The located assembly's
manifest definition does not match the assembly reference. (Exception
from HRESULT: 0x80131040)
I know the error message indicates that it is dependent on Microsoft.Crm.Workflow version 5 and the current dll available is version 8. What I don't understand it why the plugins execute successfully and the custom workflow activities do not. Do I need to rebuild my plugin assemblies with the new dll references for 2016?
thanks
The short answer is you most likely just need to recompile (and subsequently re-register) the workflow project against the latest CRM 2016 SDK assembly.
As far as I know there are no compatibility or signature changes with respect to the plugin and workflow execution methods which you are extending. This would explain why you don't get any errors when you register against the new system.
Speculating as to why you are getting the error you are (I can't be sure either is the cause, but perhaps it is):
I imagine the 2011 SDK DLL which defines the workflow execution methods you are extending is loading other CRM system DLL's in the background which are either no longer in existence or have been replaced by a newer version which doesn't have the same compatibility. In other words - the signature of the method you are compiling against is the same and is compatible with CRM 2016, however the dependencies of it (which are likely loaded at runtime) are no longer valid.
If you are using a library registered in the GAC, if this library is compiled against the 2011 DLL, recompile it against the 2016 version and then re-register it on the server.
Related
I have recently upgraded a 2006 BizTalk project to BizTalk 2020 using VS 2019.
This Project has a orchestration that call a Microsoft workflow (XOML).
The workflow 3.5 have been deprecated, but I managed to get the projects compiled by installing
Office Developer Tools
It looks like BizTalk Server 2006 extensions for Windows Workflow Foundation SDK was installed to call the workflows, but I have as yet not been able to find a replacement. From what I can see the code is that a project was generated by using BiztalkActivities. But the BiztalkActivities is old and I don't want to reuse the DLL if possible.
Has anyone run into this problem and what was done to get it working in BizTalk 2016-2020?
What is the best way to call a workflow? Is this using a long running workflow service?
I'm trying to publish my app on the Microsoft Store. When I run the Windows App Certification Kit I receive for each action an error related with Microsoft.Windows.SoftwareLogo.TestBase.
I'm using Visual Studio 2017 Version 15.9.3
Bytecode generation
Error Found: The bytecode generation test detected the following errors:
System.NullReferenceException: Object reference not set to an instance of an object. at Microsoft.Windows.SoftwareLogo.Tests.Utility.IsPackageWWA(AppXPackage package) at Microsoft.Windows.SoftwareLogo.Tests.BytecodeGenerationCheck.BytecodeGenerationCheck.ExecuteSharedValidation(String manifestFilePath, String packageFullName) at Microsoft.Windows.SoftwareLogo.TestBase.TestBase.ExecuteTest()
Impact if not fixed: As a performance optimization to accelerate JavaScript execution time, JavaScript files ending in the ".js" extension generate bytecode when the app is deployed. This optimization significantly improves start-up and ongoing execution times for JavaScript.
How to fix: You may need consider one or more of these steps to fix the issue:
- Avoid deploying the app by pressing F5 in Visual Studio, create an app package instead
- Ensure that event logging is enabled
- All JavaScript files are syntactically valid; otherwise exclude the respective files from the package
- Please note that you should uninstall all previous versions of the app before deploying
Otherwise exclude the respective files from the package.
I verified in my Visual Studio Installer and the Windows SDK in installed.
Also, I checked the targeting version of the project:
Target version: 1809 (10.0; Build 17763)
Min version: November Update (10.0; Build 10586)
There is not SDK for this build...
I am using Visual Studio 2015 (Pre), Framework 4.5.2
I have the folowing project structure
StorageProject
nuget package Microsoft.WidowsAzure.Storage is installed
This Nuget package has (among others) dependencies on Microsoft.Data.OData, wich is also installed
AnotherProject
Has a refernce on StorageProject
Does not have any nuget package or other refernces (except default references on the framework)
Here is the list of the packages installed in StorageProject
WindowsAzure.Storage 4.3.0
Microsoft.WindowsAzure.ConfigurationManager 3.1.0
System.Spatial 4.3.0
Microsoft.Data.Edm 5.6.4
Microsoft.Data.OData 5.6.4
Microsoft.Data.Services.Client 5.6.4
These are all dependencies of WindowsAzure.Storage, latest versions.
There is no other version of these packages installed anywhere on the solution.
I will focus on Microsoft.Data.OData, but the same problem occurs with Microsoft.Data.Edm and Microsoft.Data.Services.Client 5.6.4
When building StorageProject, the correct version of these dll (5.6.4) ends up in the bin folder of the project.
But when building AnotherProject, the bin folder contains version 5.6.2 of the dll.
Now I passed all day trying to figure out where these dlls come from.
There is a version 5.0.0.0 in the GAC, wich I cannot uninstall. (gacutil yields it is used by something).
I did a file search on C:\ to find that the only place where this version of the dll is (beside the bin folder of my project) is in C:\Program Files (x86)\Microsoft WCF Data Services\5.6.2. If I delete (move) this folder, my project builds "normally" and everything is fine. In fact, in this case OData is not in the bin folder at all. And as far as I am concerned, that's ok this way.
Now the real question(s) :
Why is it the version from Microsoft WCF Data Services that ends up in the bin, instead of the version actually installed in the referenced project?
Where does Microsoft WCF Data Services comes from ? I don't remember installing it at all, maybe it comes with a version on Visual Studio? (I have 2012, 2013 and 2015 installed)
Can I uninstall it? I don't see it in Windows' control panel.
•Why is it the version from Microsoft WCF Data Services that ends up in the bin, instead of the version actually installed in the referenced project?
This could be due to the fact that the storage client does not depend on a specific version of the Data Service Client. Since Specific Version is set to false, the GAC will be searched first during compilation, any version will be considered "acceptable", and no other version will be exported.
•Where does Microsoft WCF Data Services comes from ? I don't remember installing it at all, maybe it comes with a version on Visual Studio? (I have 2012, 2013 and 2015 installed)
It could be installed due to a variety of reasons. The Azure SDK contains this as well. So if you ever installed the Azure SDK, it could have come with that.
•Can I uninstall it? I don't see it in Windows' control panel.
Looks like this is only possible by uninstalling the MSI package that installed the assembly via Add/Remove programs. For that, you would have to again figure out which installation brought this assembly with it and check whether that is needed or not.
The solution is very simple but impossible.
I have office 2010 and office 2012 installed, VB6 fails to create a Word application object giving me no more than just a message saying that the DLL is not registered.
All attempts to remove and restore the DLL using the installer or third party DLL fails.
After removing everything office related and only installing office 2010, the application object gets created successfully. But this is not a viable solutions for our customers: we can't have them removing their Office suites for this.
Is there any other way?
I had a similar issue on my dev machine with two versions of office. Cast your eye over this article from Microsoft support they mention the /regserver command line option. The article is Office automation when multiple versions of Office are installed. By the looks of it I don't think you can force it to pick one version or the other but the /regserver will help you in your dev environment.
We are generating Interop dll for wuapi.dll using tlbimp.exe. Is this interop dll genrated by tlbimp.exe dependent on OS version?
Are there any dependencies on wuapi.dll that has to be packaged if this has to packaged and installed on client machines?
For more context :
C# code to find all office updates installed
How do I get a list of installed updates and hotfixes?
wuapi.dll has an OS dependency so the interop library does as well. Judging from the interface names there may be 6 versions of it out there. I see IUpdate through IUpdate5 for example on Win7. Trying to use a newer interface is liable to fail if you're running on an old version of Windows. Which interface is available on what version of Windows isn't documented in the MSDN library articles, you'll have to test this yourself. You can get old versions of Windows through an MSDN subscription.
Nothing but the interop library should be deployed, this is an operating system component.