My ASP.NET application uses some 3rd assembly. What are my options to make the application load that assembly? Do I have to put it in the GAC?
I don't want to modify the machine's PATH env variable...
You can put it into your application folder (best solution) or add a codebase tag in your web config like explained in this msdn entry:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="MyAssembly2" culture="neutral" publicKeyToken="307041694a995978"/>
<codeBase version="1.0.1524.23149" href="FILE://C:/Myassemblies/MyAssembly2.dll"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Add it to the GAC only if you want to share that assembly.
Is your assembly strongly named?
You can either put it in the GAC or reference it in your web.config (using a <codeBase> element according to this MSDN article.
If not
The assembly has to live in the bin folder of your web application.
Related
We have an Excel Addin developed in C# and integrated with ExcelDna.
It worked fine for many years.
But now for one customer it runs with slow performance.
I added some logging and can't figure out any significant slow part in the code.
It seems that in general every piece of code is a bit slower and for longer running tasks the total loss of time is significant.
The Addin runs in its own AppDomain and because of some Nuget dependencies, we use AssemblyRedirects specified in the config file of the Addin, which is used by the AppDomain.
And now the funny/weird finding:
My colleague added those Redirects to the Excel.exe.config and voila: it runs fast.
What the heck is going on here?
Well, it kinda fixed the problem, but of course we don't wanna manipulate the config file of Excel.
We figured out, that if only one of these two redirects exist in the Excel.exe.config, the Addin runs fast:
<dependentAssembly>
<assemblyIdentity name="System.IO.Compression" publicKeyToken="b77a5c561934e089" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.1.2.0" newVersion="4.1.2.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Numerics.Vectors" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.1.4.0" newVersion="4.1.4.0"/>
</dependentAssembly>
Any help on that is appreciated.
I am building a windows installer for my .NET application and it looks like InstallShield (2012 Spring - Premier Edition) is adding Windows Common-Controls manifest to my icons converting them to DLLs.
This is hitting my application's performance as OS encounters a page fault as it tries to parse the icon image on launch.
Here is the manifest that IS is appending.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="CompanyName.ProductName.YourApplication"
type="win32"
/>
<description>InstallShield Icon Res</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="<>"
language="*"
/>
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="asInvoker"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
First a short digression into why this is happening. The Icon table, where Icons need to be stored to support Windows Installer advertisement, requires that "Icon files that are associated with shortcuts must be in the EXE binary format and must be named such that their extension matches the extension of the target". Thus InstallShield builds the correct format file. And by "build" I really mean it stuffs the icon data in a resource on a template EXE file.
So what's the upshot? You can change the resulting manifest by editing the template. The template is stored in ...\Support\_IsIcoRes.exe, and if you open that in Visual Studio or another resource editor, you can examine or even edit the manifest in RT_MANIFEST (24) \ 1. This file isn't signed (yet) because the build process will have to modify it, and thus would invalidate any signature, so your edits should be safe. That said, keep a backup of the original in case things go awry.
I have a workflow project in my solution that referenced Microsoft.Activies.Extensions.dll 2.0.2.16
I used the NuGet Package Manager to upgrade to the current version 2.0.6.9
Deploying the web role that references the workflow project .dll to the cloud I get:
Could not load file or assembly 'Microsoft.Activities.Extensions, PublicKeyToken=23b0c89d0d5ad43f' or one of its dependencies. The system cannot find the file specified.
I remote desktoped to the VM and checked the F:/approot/bin to see that neither version of the assembly was deployed.
Since this a NuGet package I can find it in my <Solution root>/Packages folder. I see the new folder created by NuGet but also the old version folder that was left behind although the assembly was not inside. I deleted that folder and put an assembly redirect in my web.config:
<dependentAssembly>
<assemblyIdentity name="Microsoft.Activities.Extensions" publicKeyToken="23b0c89d0d5ad43f" />
<bindingRedirect oldVersion="2.0.2.12" newVersion="2.0.6.9" />
</dependentAssembly>
Clead, build, re-deploy via Publish.
The error persists, and digging into the approot/bin again shows that the assembly was still not deployed.
I, of course, have Copy Local set to true.
Why is it not getting deployed?
Ok, resolved from finding this article:
http://weblogs.asp.net/albertpascual/archive/2008/12/16/the-cloud-for-a-fast-deployment-of-proof-of-concepts.aspx
Turns out when a web-role references an assembly than in turn references other assemblies, those assemblies will not be deployed even if Copy Local = true.
The solution is to references those child dependencies directly in the web-role project with Copy Local to true.
Only then did they show up in my approot/bin upon deployment.
I (successfully) deployed some sharepoint2010 - Webparts using msbuild. Everything works fine until I decided to change the assemblyVersion. Whenever I do that the message
Web Part Error: A Web Part or Web Form Control on this Page cannot be displayed or imported.
The type RTContacts, RTContacts,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=2721ba85ef1e4b88 could not be found or it is not registered as safe.
A solution would be to stay on 1.0.0.0, but there should be a better way...
Perhaps interesting to mention is that we use a centralized AssemblyFile which is included as a link.
The manifest contains the correct assemblyversion:
<Assemblies>
<Assembly Location="RTContacts.dll" DeploymentTarget="GlobalAssemblyCache">
<SafeControls>
<SafeControl Assembly="RTContacts, Version=1.0.4325.18399, Culture=neutral, PublicKeyToken=2721ba85ef1e4b88" Namespace="RTContacts" TypeName="*" />
</SafeControls>
</Assembly>
When I add the WebPart again to that Site, it is displayed correctly, but already existing webParts seem to link to the old version.
You are having these problems because you're using the versioning attributes incorrectly.
If you examine, for example, Microsoft.SharePoint.dll in Reflector you will see v14.0.0.0 (for SharePoint 2010).
This AssemblyVersion will stay exactly the same for Beta, RCx, RTM all service packs and CU's etc - the only thing that changes is the AssemblyFileVersion (this is the thing you see in Windows Explorer under properties)
See this for more details
SharePoint features: How can I use wildcard assembly versioning?
But don't take my word for it - Microsoft KB556041 - How to use Assembly Version and Assembly File Version
If you follow this then no Assembly binding redirections are necessary and when you update your web part the existing instances will not be broken.
Original question: How to fix the "Not registered as safe" error after the assembly version has been changed?
Web Parts are registered as safe in the web.config files.
Appropriate entry looks like this:
<SafeControl Assembly="MyWebPartLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"
Namespace="MyWebPartLibrary"
TypeName="*"
Safe="True"
AllowRemoteDesigner="True"/>
Modify the Assembly attribute and replace the old version number with a new one.
Current question: How can I change assembly version without having to re-add all the Web Parts to the page?
I think you'll need to use assembly redirection to keep existing Web Part instances working:
<runtime>
<assemblyBinding>
<dependentAssembly>
<assemblyIdentity name="RTContacts" publicKeyToken="2721ba85ef1e4b88" culture="neutral" />
<bindingRedirect oldVersion="1.0.0.0" newVersion="1.0.4325.18399" />
</dependentAssembly>
</assemblyBinding>
</runtime>
Read the article Web Part Versioning with assembly redirection for a detailed analysis of this problem.
It is possible to add keys to the web.config by creating a file: 12/CONFIG/webconfig.name.xml
(See http://msdn.microsoft.com/en-us/library/ee413929.aspx)
With contents:
<actions>
<add path="configuration/SharePoint/SafeControls">
<SafeControl
Assembly="CustomWebPart, Version=1.0.0.0, Culture=neutral, PublicKeyToken=123456789abcdefgABC"
Namespace="CustomWebPart"
TypeName="*"
Safe="True" />
</add>
<add path="configuration/runtime/assemblyBinding">
<dependentAssembly>
<assemblyIdentity name="CustomWebPart" publicKeyToken="123456789abcdefgABC" culture="neutral" />
<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0" />
</dependentAssembly>
</actions>
This works great for adding safe controls, but it doens't seem to work for assembly redirects. Does anyone have an idea why this doens't work? Is it maybe the case only tags inside "configuration/SharePoint/" can be added?
You can't add binding redirects on deployment with configuration files in SharePoint 2007 (though you can in 2010) so you would have to write code to do this using SPWebConfigModification.
Beware though its not easy - just search on SPWebConfigModification and check out the first page of results.
As an alternative I've got to ask why you might want to do this - if this is just versioning minor changes (i.e. v1.1 > v1.2) then perhaps this is not the best way to do this - check out file assembly versioning instead.