In Microsoft Dynamics CRM 2011, I wrote one plug-in in C# for Account entity to do some operations on fields when Account record is created. In C# code I created my own custom assembly called My.Custom.Assembly.dll. Which contains some generic methods those I can use often in my plug-in. And I using this My.Custom.Assembly.dll and also added in reference in my project. Project builds successfully and plug-in registration also. The problem I faced when I was creating a Account record. Its throwing an error: "Could not load file or assembly My.Custom.Assembly.dll, Version=1.0.0.0 Culture=neutral, PublicKeyToken=def751c98b41d765 or one of its dependencies.The System cannot find the file specified." I got to know the problem is with My.Custom.Assembly.dll. Can you please help me to solve this problem..?
Your custom assembly cannot be loaded during the execution of your plugin.
Either install it in the GAC or merge it with your plugin assembly.
See my answer at Plugin with references not working on CRM 2011
A good place to start debugging this type of issue is to use Fusion Log Viewer to see the details of how .Net runtime is attempting to load the assembly. http://msdn.microsoft.com/en-us/library/e74a18c4(v=VS.100).aspx
Based on what you find in the log post more details if you need additional assitance.
You may also want to read up on How .net loads Assemblies
Related
I add licensed select.pdf.dll to my SharePoint project. This dll file has added in both the visual studio reference and the package section(Deploy target as 'Global Assembly Cache (GAC)').
I was not able to deploy my solution to my sharepoint development server, with the error message
“Error occurred in deployment step 'Add Solution': Error: Cannot add the specified assembly to the global assembly cache: Select.Pdf.dll.”
I have googled the problem, someone cannot deploy because the .dll they want to deploy already existed in %windir%\assembly folder and the .dll is locked by other process.
VS2015 build error: Cannot add the specified assembly to the global assembly cache
https://devramblings.wordpress.com/2011/03/23/error-cannot-add-the-specified-assembly-to-the-global-assembly-cache/
However, the "Select.Pdf.dll" I want to deploy has never been deployed before, the %windir%\assembly and %windir%\Microsoft.Net\assembly folders do not have same name dll. file in them.
I have tried to restart VS, and reset IIS. the problem still existed.
Is there any way to solve the problem? Thank you.
You need to add the relevant .dep files also. When you add your assembly to the advanced section of the package you can add Class Resources at the bottom of the dialog. In my case I had to add Select.Tools.dep and Select.Html.dep before I could deploy my sharepoint solution.
#Mundi's answer works, only clarification is that for us, only selecting Select.Html.dep was enough. It is to be noted that you have to specify that you want to view all files (not just .dll) when selecting the additional Class Resources.
Alternative solution that worked for development scenario (but not advisable for production) is using appropriate gacutil.exe to your .net version.
I have a strange issue.
When I publish my MVC site to Azure it works.
When I hook it up to deploy using continuous integration on check-in I get a missing dll:
Could not load file or assembly 'Microsoft.Owin, Version=2.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I can't work out what is going on as the code base is always the same!
All, after reading a couple of comments I have uploaded the following images. All my Owin references are coming from Nuget but it looks like I have a few different version numbers of Own references. I don't know why this would be as the web project.
I have searched my project for the word Owin and found there are very few references and, as you can see in this image, there are 3 different version numbers for various DLLs that are related to Owin:
Also, here are all the references to Owin in my Visual Studio Online build log:
Maybe someone can comment on why there are varying version?
thanks
Russ
I'm getting a run time exception in my deployed, exported, and then imported to another box... CRM Solution. The Exception is:
System.TypeLoadException: Could not load type 'System.Runtime.CompilerServices.ExtensionAttribute' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
It only occurs when I use a MSBUILD script to do this. When I use VS (2010) by hand to do this, all is well. So, first suspect is my script. My script uses a MSBUILD custom task, inspired by http://fczaja.blogspot.com/2012/07/continuous-integration-with-crm.html.
My sense is the issue could be on the Export step - which uses the Microsoft.Xrm.Sdk.Client.OrganizationServiceProxy, up-cast to IOrganizationService.Execute, passing an ExportSolutionRequest object. We set the SolutionName and Managed properties only. Perhaps we're missing another property?
I'm trying to narrow it's root cause.
Are you by any chance using ILMerge on your plugin assembly?
If so I suspect it is an issue with your reference assemblies, perhaps having .NET 4.5 on the build server but not on the machine where you build it manually.
These links will explain futher if this is indeed the case:
http://www.mattwrock.com/post/2012/02/29/What-you-should-know-about-running-ILMerge-on-Net-45-Beta-assemblies-targeting-Net-40.aspx
The fundamental fix is to change your ILMerge reference assemblies to be -/targetplatform:"v4,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0"
In order to get Portable Library Projects v2 working in MonoTouch, I'm currently jumping through a small number of hoops.
One of them is that I'm building a forwarding DLL for System.Net methods (see some explanation in http://slodge.blogspot.co.uk/2012/04/using-portable-library-tools-for.html)
However, I'm having some problems actually generating a DLL with the right name - because if I generate it as System.Net then I get an error during build of:
Error CS0281: Friend access was granted to System.Net,
PublicKeyToken=7cec85d7bea7798e', but the output assembly is named
System.Net, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'.
Try adding a reference to `System.Net,
PublicKeyToken=7cec85d7bea7798e' or change the output assembly name to
match it (CS0281) (System.Net.Touch)
I do have a way around this - generating the file under a different name and then manually renaming it afterwards. But I'd prefer to avoid this step if I can.
Can anyone suggest a way to avoid this error while still generating an assembly called System.Net?
Not sure if that helps. I was able to take your code and build a delay signed System.Net, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e in Visual Studio 2010. Then successfully used that DLL to build a simple application (One PCL + One MonoTouch) to compile and run in both VS/Windows and Xamarin/Mac.
After months of research on this, it seems that the only way to do this within a solution is the workaround I already had:
I do have a way around this - generating the file under a different name and then manually renaming it afterwards. But I'd prefer to avoid this step if I can.
Hopefully this won't be needed soon anyway - as we have official Xamarin PCL support under production right now.
I deployed some solutions to Sharepoint Central Administration.
After this, the Central Administration can't open. this error appear when I try access the site:
Error
Could not load file or assembly
'Microsoft.SharePoint.Publishing, Version=14.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c' or one of its dependencies. The
system cannot find the file specified.
I saw at some blog this error occur because the solution isn't compatible with sharepoint foundation.
So I uninstalled all solutions from site using PowerShell's Command. But the error persist.
What I need to do to fix it?
I assume you only have SharePoint Foundation installed since you get this error, (and not SharePoint Server).
I would check the web.config of the central admin website for references to 'Microsoft.SharePoint.Publishing'. Probably the custom solutions you installed left some traces there and that's causing your problem. It's not pretty but you'll probably need to remove these references manually.