Has anyone used WSP Builder to package a solution that uses the Config Store (http://www.codeplex.com/SPConfigStore) and deploys to the bin directory of the web application?
When I try to referecne the config store in my code behind file I get this exception...
System.Security.SecurityException: That assembly does not allow partially trusted callers
I've added the partially trusted callers attribute to my project
[assembly: AllowPartiallyTrustedCallers()]
and the sharepoint permissions attributes on my methods
[SharePointPermissionAttribute(System.Security.Permissions.SecurityAction.Demand, Impersonate = true)]
[SharePointPermissionAttribute(System.Security.Permissions.SecurityAction.Demand, ObjectModel = true)]
But this hasn't seem to have done anything, I've also specified a custom CAS policy with the correct IPermission
<IPermission class="Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" version="1" ObjectModel="True" UnsafeSaveOnGet="True" Unrestricted="True" />
And still no success, surely other people have done this, I must be missing something
I'm using WSP Builder version 1.0.5.
You have added the [assembly: AllowPartiallyTrustedCallers()] to YOUR assembly, so your assembly WILL allow for partially trusted callers to call IT.
But the ConfigStore itself does not have that attribute.
Is it possible to add your DLL to the GAC? (easy way out).
Or add the [assembly: AllowPartiallyTrustedCallers()] to the ConfigStore project as well..
Did you add the assembly to the web.config SafeControls section?
<SafeControl Assembly="Microsoft.Office.Server.Search, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.Office.Server.Search.WebControls" TypeName="*" Safe="True" />
Also you may need to lower the trust level in the web.config:
<trust level="WSS_Minimal" originUrl="" />
See the MSDN docs for ASP.Net and SharePoint trust levels.
Related
I'm currently attempting to convert an older project from VS2013/MVC3 to use VS2015/MVC5, and I've ran into a problem where any old ASPX view (.aspx/.ascx) that sets a strongly-typed model causes a build error.
I've tried with a clean project made from scratch, and the same error occurs, so it makes it fairly simple to reproduce:
File > New > Project.
Create a new ASP.NET Web Application Project.
Select ASP.NET 4.6 Templates > MVC, then click OK.
Create an .ascx file in Views\Home. (Note that VS2015 doesn't have tooling to create such a file, so you'll have to create a text file and rename it or something.) It should contain:
<%# Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl<TestClass>" %>
Either create a new model class (like I did with TestClass), or use one of the pre-built Identity models contained in the project.
Add a call to #Html.Partial("<your_user_control>") to Home/Index.cshtml.
Run the project.
This is what I get when I do the above:
This is the version of VS2015 I'm using:
I've tried searching for every possible permutation of search that could uncover this issue, but all I could find is posts confirming that ASPX/ASCX views are indeed supported in VS2015/MVC5, or posts about old versions of MVC.
Any solutions?
A generic type declaration written in C# like ViewUserControl<TestClass> has to go into a C# code-behind file. Otherwise, you have to specify a CLR type name:
<%# Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl`1[[MyWebApplication.Models.TestClass, MyWebApplication]]" %>
Turns out you need to ensure a web.config (either your project's base one, or the ones in your base Views folder and the ones for all of your areas) has the following in there somewhere:
<system.web>
...
<pages
validateRequest="false"
pageParserFilterType="System.Web.Mvc.ViewTypeParserFilter, System.Web.Mvc, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"
pageBaseType="System.Web.Mvc.ViewPage, System.Web.Mvc, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"
userControlBaseType="System.Web.Mvc.ViewUserControl, System.Web.Mvc, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
<controls>
<add assembly="System.Web.Mvc, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" namespace="System.Web.Mvc" tagPrefix="mvc" />
</controls>
</pages>
...
</system.web>
The web.config that come with the default project created in VS2015 does not include this, presumably because they assume (and probably rightly so) greenfield projects won't use the Web Forms view engine.
I found the above by double-checking the ASP.NET MVC 4->5 upgrade docs again.
During the deploy to production we have to add a number of additional entries to the application's web.config, for example adding subkeys to system.identityModel/identityConfiguration/audienceUris, which is declared at the top of the web.config file as
<configSections>
<section name="system.identityModel" type="System.IdentityModel.Configuration.SystemIdentityModelSection,
System.IdentityModel, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=B77A5C561934E089" />
</configSections>
In an ideal world we would do this using config transforms at build time, but we've made a design decision to use msdeploy parameters instead, which don't allow the injection of XML nodes in parameters (in spite of various posts that suggest you can). There are solutions that allow you to use both but we don't have time to integrate those into our deployment infrastructure right now.
Ideally we would achieve our end using appcmd to add nodes in the msdeploy post-sync task, but it seems that out of the box appcmd does not expose these custom sections unless you also declare them in applicationhost.config.
Is there a way to use appcmd or other tools to programmatically update applicationhost.config to add these declarations or do we just have to work with the XML directly?
I am using Service Bus in my project. I am referring Version 2.0.0.0 dll.
When I add following tag in my app.config everything works fine
<extensions>
<bindingExtensions>
<add name="netTcpRelayBinding"
type =
"Microsoft.ServiceBus.Configuration.NetTcpRelayBindingCollectionElement,
Microsoft.ServiceBus, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" />
</bindingExtensions>
</extensions>
but as soon as I remove this tag, it gives following error
Configuration binding extension 'system.serviceModel/bindings/netTcpRelayBinding' could not be found.
Verify that this binding extension is properly registered in system.serviceModel/extensions/bindingExtensions and that it is spelled correctly.
Is it mandatory to provide this tag because on some other machine it is working fine without this tag.
This is required for WCF to be able to load this binding from the correct dll. There are cases where you can add this to other config files like machine.config and WCF will pick it from there and hence the app will work without having it in the app.config file.
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 just come to revisit an old virtual sharepoint 2010 install. When I crank up central administration I get the following error:
The module was expected to contain an assembly manifest. (Exception from HRESULT: 0x80131018)
Line 379: <compilation batch="false" debug="false">
Line 380: <assemblies>
Line 381: <add assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
I have looked in the GAC and the assemblies are there.
I have ran the central administration configuration wizard through to see if this repaired the issue.
Can anyone suggest and an approach to resolving this?
all the best
Right, I think it was an application pool setting that was the issue. The central admin app pool was set to framework version 2.0 - I have changed it to 4.0 and am now past this error.
I think this is the cause of the issue but would appreciate anyone's views on this.