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.
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'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 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
During solution deployments & Feature activation, I am facing an on/off issue where the system is unable to find & load the FeatureReceiver class. Mostly it is file not found exception (even though the assembly is there in the GAC). I checked over the net and this seems it a common issue with solutions (wsp) packaging DLL to be GACed. (But, no one has any clue or solution!)
What is the recommendation and guideline to fix this issue? We are setting the flag to reset IIS in my solution definition - but that does not seem to help. The issue is more prevalent in multi-M farms.
Thanks
This is a general problem in SharePoint in cause of the "SharePoint 2010 Timer Service". Because this one caches the wsp's and during the deployment or feature activation old references will occurres this error!
So try the following link. I hope this solution will help you.
http://msscorner.de/en/2011/10/27/sharepoint-deployment-failed-to-create-receiver-object-from-assembly/
First try the solution linked to by Falco...
If that does not help, try this:
Open the event-receiver file created by sharepoint
Compare the GUID above the event-receiver-class with the one stated in the stack-trace "...class=7g3562-438dn4...
If it does not match:
Copy the content of the class
Delete the file
Create a new file by right-clicking the feature -> add new event reciever
Pass the content
First thing, you dont need to give iisreset as your wsp deployment would have already done that.
Can you check if the assembly name, version, public token specified in the feature.xml is same at the actual assembly that is deployed in gac? I am thinking there is mismatch in assembly signature
I created a code behind file for a custom master page in visual studio. I hooked everything up manually; safe control and custom cas policy. Everything works great!
I then wanted to put this into a sharepoint solution using WSPBuilder for better deployment. I created WSP solution, added my class file and changed the output directory to the bin folder. I then built the solution and deployed it, making sure to change the page directives on the master page to reflect the new assembly name.
Now when I go to view the sharepoint site I get an error stating Security Exception error stating
‘Exception Details: System.Security.SecurityException: That assembly does not allow partially trusted callers.’
This has me stumped as it works as a visual studio class file deployed to the bin directory of the website.
However when I put this into a sharepoint solution it breaks! I tried adding
‘[assembly: System.Security.AllowPartiallyTrustedCallers]’
to the AssemblyInfo.cs but this hasn’t helped.
Anyone else experinced this or have any advice?
EDIT: I should also mention that the code behind is trying to access a sharepoint list.
Don´t you still have to include the SafeControls entry in order for it to work, like:
<SafeControl Assembly="[FullAssembly Name]"
Namespace="[YourMasterPageNamespace]"
TypeName="*"
Safe="True" />
or in WSPBuilder config:
<add key="BuildSafeControls" value="True" />
Never seen this.. but I suspect not many people have created codebehinds to the master pages in SharePoint (Microsoft doesn't too!).
I don't know what you are trying to build but I'd probably implement it using a server control that is included on the master page.
AllowPartiallyTrustedCallers has always fixed it for my server controls.
What is the trust in your web.config file set to? Try Full.
Are you calling a third party assembly?
I ran into a situation recently that I was using a third party assembly and it did not have AllowPartiallyTrustedCallers in its code. When I tried to use the assebmly, it would fail.
Are you sure that the assembly has been deployed to bin and no to GAC by accident? If there are two assemblies the one in GAC takes precedence.
You might try checking that you are using the fully qualified five part name including the correct public key token and namespace for your assemblies.