I created a workflow and i am using some external dlls. How to register them in crm 2013 online, because when i try to run workflow it gives me error. Will i have to merge the dlls? or something else.
You will have to use ILMerge to include referenced assemblies to output assembly. This article describes how to do it.
Related
There is a bug in the WiX plugin for Visual Studio where file locks on referenced DLLs are not properly released. Therefore, you have to restart Visual Studio every time you want to recompile a custom extension DLL or any assembly referenced by it.
This is a known bug, but the issue was closed because there seems to be a solution / workaround:
You can force the WiX .exes to run out-of-process to avoid the lock
MSBuild has.
I don't understand how to achieve this. I checked...
the properties of my WiX setup project
the properties of the extension assembly (C# class library)
all Visual Studio settings
the available command line arguments of candle.exe
...but did not find anything. What am I missing? How do I apply this workaround?
I'm using WiX 3.10 and Visual Studio 2013.
The example that I've seen several times around the web is to add <RunWixToolsOutOfProc>true</RunWixToolsOutOfProc> to the Wix Installer's project file within a property group. Unfortunately, documentation of this feature has thus far eluded me.
The custom build activity depends on the following TFS assemblies:
Microsoft.TeamFoundation.Build.Client.dll
Microsoft.TeamFoundation.Build.Workflow.dll
Microsoft.TeamFoundation.VersionControl.Client.dll
The goal is to compile it in such a way that it will work on TFS 2010, TFS 2012 and TFS 2013 without having to manually specify binding redirections for all the possible Build Agent machines where the activity might be invoked.
Supplying a configuration file along with the activity and creating an application domain that uses the binding redirections specified in that configuration file seems like an option, but this ultimately would not work, since the "Microsoft.TeamFoundation.Build.Client.BuildActivity" attribute that the activity must be decorated with* would be read by the calling code before the code in the custom activity's assembly is executed - and if the version of the TFS assembly that that attribute came from does not match the version of the TFS assembly loaded in memory, the activity is as good as if it weren't decorated with that attribute at all.
(* I have confirmed that if a custom activity is not decorated with the BuildActivity attribute, the custom activity's type cannot be created and the build fails.)
Removing all references to TFS activities and loading TFS-related types using reflection also seems like another option, but would fail for the same reason, since obviously the BuildActivity attribute cannot be reflectively applied to the class before the code inside the class itself is called by external code.
Since the few TFS types and methods the activity depends on exist in the TFS 2010, TFS 2012 and TFS 2013 assemblies and since the activity is compiled against .NET 4.0, the only reasonable workaround I can think of is to create 3 separate builds: one compiled against the TFS/VS 2010 (10.0.0.0) assemblies, one compiled against the TFS/VS 2012 (11.0.0.0) assemblies, and one compiled against the TFS/VS 2013 (12.0.0.0) assemblies.
(And of course, while I have the TFS2010/TFS2012/TFS2013 versions of the above assemblies on my development machine, the assumption is that the Build Agents will have only the version of those assemblies that comes with its version of TFS.)
The other workaround seems to be to specify binding redirections for all the Build Agent machines, but with a rather large number of Build Agent machines this is not feasible.
Is there an actual solution to this problem or am I stuck having to create 3 builds?
if you go down the route of having 3 assemblies, technically you could create 3 BuildProcessAssemblies folders and add the
Microsoft.TeamFoundation.Build.Client.dll
Microsoft.TeamFoundation.Build.Workflow.dll
Microsoft.TeamFoundation.VersionControl.Client.dll
libraries to each folder, then point each particular controller to the relevant folder.
I am developing monodroid with Visual Studio 2010.
I have a .net library containing the business logic and my monodroid application. In the monodroid application i use the business logic library. (Add reference...) When i debug know and want to step into a method call that goes to the library the step is just skipped by the debugger and i continue in the monodroid application.
Does anybody know a solution ? Like this it's really hard to develop...
If you are just referencing a DLL, Visual Studio won't know about where to find the source for it normally and VS does not have a de-compiler built in. So you will need something like Reflector or link the project with the Business Logic into the Solution and use a project reference in the project you are debugging instead.
Here's my story: I've imported my CRM 4 solution to CRM 2011. Most things look OK, plug-ins mostly work. This import process was done through the CRM Deployment Manager.
Step 2 I wanted to test building a Solution, adding all my customizations to it, export it, and import it to a second organization on the same server.
Its gotten fairly close (its a HUGE improvement over CRM 4). But its failing when it goes to load my plug-in assembly. The CRM Trace and event log aren't providing me any more help than the solution import log file:
Failure 0x80044191 Unable to load
plug-in assembly.
My assembly is deployed to disk so its available. I tried unzipping the solution file, and adding my assembly in the solution hierarchy but that didn't help.
Is it because they're CRM 4 plug-ins? Must they be updated to be imported in CRM 5?
Ended up being I was referencing an assembly not in the GAC of the new server. Wasn't related to solutions per-say and I couldn't register directly with the plugin registration tool either (though that gave me more information). So if you see this I recommend trying to register the assembly using the plugin registration tool to get better information.
You should be able to register your old plugins; upgrading plugins isn't required. Have you tried registering the plugin to database instead of disk? Are you able to register this plugin against your 4.0 environment?
See Upgrade Plug-ins and Custom Workflow Activities to Microsoft Dynamics CRM 2011 for more info about upgrading if you decide to try that.
Actually when you try to import your solution in new organization of MS CRM2011 it is throwing exception because MS CRM4.0 plug-ins are using a library "microsoft.crm.sdk.dll" which does not exist in the GAC. Here is a workaround for the registration of MS CRM4 Plug-ins in MS CRM2011 http://social.microsoft.com/Forums/en/crmdevelopment/thread/d3ce2b89-e8d3-4334-9117-fda2193e03a8
Does your plugin assembly have any dependencies (except the obvious microsoft.crm.*)? If so, try to ILMerge everything into one big DLL and deploy it to the database.
I have installed the 2007 PIA and repaired my Office 2007 installation.
Still, when I add a reference to the Office 12 Object Library in VS2005, I only see Office.Core and cannot add an 'imports' statement for Office.Interop
I have checked that Windows\assembly\gac\ has got the interop dlls.
With the PIAs installed, you have to add a reference to the corresponding COM library - instead of generating an automatic interop, the PIA will be used instead.
To quote Microsoft's documentation
For Microsoft Office applications that do not have projects in Visual Studio Tools for Office, you must add a reference to the appropriate application or component to your project manually. Adding a reference to the component references the primary interop assembly, if the assembly is installed in the global assembly cache. Office applications and components are accessible from the COM tab of the Add Reference dialog box.
Add a browse reference. You have to ship the PIA dll to get any benefit out of it anyway.