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.
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 (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.
I have a classic asp application inside a .NET 4.0 application. I have set the default document to login.asp, but it does not automatically redirect to it. The entire application functions fine though and even displays the login.asp correctly if I browse to it.
The default document section in web.config is as below:
<defaultDocument>
<files>
<clear />
<add value="login.asp" />
<add value="index.html" />
<add value="default.aspx" />
<add value="Default.htm" />
<add value="Default.asp" />
<add value="index.htm" />
<add value="iisstart.htm" />
</files>
</defaultDocument>
I have looked at other similar questions on this site but were not of much help.
I finally found the issue was because the asp application was assigned to an app pool in classic mode using .NET Framework 4.0.
Once I changed the app pool to use .NET Framework 2.0 (with managed pipeline in classic mode), the default document started to work too!
Make sure you have Read/Write Feature Delegation enabled for Default Document:
DefaultDocument does not redirect to the file (i.e. URL is not changed). It acts similar to Server.Transfer function — executes the file when root URL (http://sitename/) is requested. Probably, your login.asp executed but it has instructions to redirect logged-in users to a different page, or display the different content to them.
Make sure the response is not cached. Clear cache and cookies and try again.
I had this problem today with a brand new asp.net site deployed to Azure. I tried messing with IIS and my web.config included
<defaultDocument enabled="true">
<files>
<clear />
<add value="Index.html" />
</files>
</defaultDocument>
Turns out my problem was that the File > New Project wizard uses .NET 4.5.2 by default, and that isn't fully supported yet in Azure. I recompiled using .NET 4.5 as the target and everything works now!
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.