SharePoint Designer 2010 Workflow Error: Could not deserialize object. The type could not be resolved - sharepoint

In development environment I have SharePoint Workflow created in SharePoint Designer. This workflow using custom activity created in Visual Studio.
After deployment web (Import-SPWeb Export-SPWeb) in production i've got error when tring to open my worklow within Designer.
Could not deserialize object. The type 'MyTypeHere' could not be resolved.
I've trying to reinstall solution and clear SharePoint Designer cache in application data. In workflow's xoml i specify right full namespace of my assembly with custom activity and this assembly exist in GAC.

Problem solved. I could not figure out how, but works fine now. 100% server was not restarted. May be it is because farm configuration and web.configs. Use feature activation to be sure that you control .config files.

Related

How to Call Custom .dll in SharePoint?

I am trying add new function inside my SharePoint and I created HTML code and it will call .dll file where I download it. However, when I run project standalone outside SharePoint it works. However, inside SharePoint code (HTML) when I add assembly to my .dll , it shows not found.
I tried adding it in SafeControl in web.config bug still same issue.
I place .dll in all places where other SharePoint .dll are there but still the same problem.
I am not sure if I understood what you trying to accomplish but I suspect you are using some SharePoint on-prem and you deploy some kind of solution (webpart or other) to a site were you want to use an external dll. If that is the case you need to create some kind of empty sharepoint farm project (or use one of the existing farm solutions) and add an external dll to it so it will be deployed to GAC. When an dll is in Global Assembly Cache then we may use it in all places in SharePoint.
Here I found some blog post how to add a external dll to GAC
I hope this will be of any help
When the project is running inside the SP server, it's different from when it's starting outside the farm. You need to ensure the dll has been copied to gac, or the server cannot find it.
If you're developing a custom WCF in SP on-premise, you may take a reference of below demo:
Custom WCF
More reference:
https://blog.mastykarz.nl/including-additional-assemblies-wsp-visual-studio-sharepoint-development-tools/
BR

Converted Web Site Project to Web Application Project - Can not access UI Controls

I have converted a large project, currently in VS 2012 from a Web Site project to a Web Application project.
I have added the namespace to all of my .cs files.
I have ran the "Convert to web application" on the project and it has generated all of the needed files. (So I do have the designer files created as part of this upgrade)
When I compile, it errors off on all of the references in my C# code behind file for all of the UI Controls. The error indicates that the control does not exist. The controls are there, and they are present in the designer files.
I have cleaned my solution and no matter what I do I get this error.
Any ideas / suggestions of things to try? Have I missed something in the conversion to a Web Application?
Fixed My Issue.. It was the inherits statement in the ASPX. I had to include the namespace along with that... Problem solved... so, the syntax is inherits="namespace.formname"

SandBox Webpart embedded inside Masterpage in SharePoint 2013 giving error

Well, SharePoint 2013 is not very Sandbox friendly. Having lots of issues.
In SharePoint 2010, I was able to successfully embed Sandbox webparts inside the masterpage using this:
<WebPartPages:SPUserCodeWebPart runat="server" Description="Description" Title="TITLE"
AssemblyFullName="$SharePoint.Project.AssemblyFullName$" SolutionId="00000000-0000-0000-0000-00000000000"
ID="ID" TypeFullName="Namespace.WP">
</WebPartPages:SPUserCodeWebPart>
However, when I add this inside a masterpage in SharePoint 2013, I get the following error:
ExecuteRequestInSandBox call failed. System.NullReferenceException: Object reference not set to an instance of an object. at Microsoft.SharePoint.WebPartPages.BinaryWebPartSerializer.Serialize(PersonalizationScope scope, BinaryWebPartSerializerFlag binaryWebPartSerializerFlags, BinaryWebPartSerializerWriter writer) at Microsoft.SharePoint.WebPartPages.BinaryWebPartSerializer.Serialize(SerializationMode mode, BinaryWebPartSerializerFlag binaryWebPartSerializerFlags, BinaryWebPartSerializerWriter writer) at Microsoft.SharePoint.WebPartPages.SPUserCodeWebPart.EnsurePersistedBlobsMatchPropertiesCollection() at Microsoft.SharePoint.WebPartPages.SPUserCodeWebPart.GetWebPartDataForRemoteCall(Object& viewState, Object& controlState) at Microsoft.SharePoint.UserCode.SPUserCodeWebPartRemoteExecutionHelper.ExecuteRequestInSandBox(HttpContext context, SPWeb web, SPWebPartManager manager, SPUserCodeWebPart userCodeWebPart)
I've tried a bunch of things, and it seems that you cannot embed a sandbox webpart onto a masterpage. However, a farm level webpart solution can be successfully embedded into a masterpage.
I have no idea why this is the behavior. You can, however, deploy an application page with SandBox WP embedded on it, and the application page will work fine. This is very interesting behaviour.
For now, I'm keeping this question open. Maybe someone will figure out this craziness.
The only bad thing is that you cannot deploy your masterpage to SharePoint Online (Hosted) because it does not allow farm-level solutions. Maybe AppParts, or iFrames, or embedded javascript/jQuery with a back-end fake service might do the trick, but for my purpose, I was looking at a bit more complexity.
I resolved this (hurrah!) by changing the version of referenced assemblies to 16.0.0.0 from 15.0.0.0 (or rather, removing the version and key parts of the assembly names altogether) in the Register tags.
Basically I think there's a bug in wave 15, fixed in wave 16.
Only problem is, my dev environment is wave 15 (as is everyone else's I presume). But removing the version number from the reference tags, it at least won't crash-out completely, just give an error message where the web part would appear.
Ran into a similar issue today on on SP farm. After installing SharePoint 2013 SP1, this is fixed. If you are experiencing this, check your patch version. If it is less than 15.0.4569, upgrade to at least 15.0.4569.

Deploying custom dll's in SharePoint 2010

I'm new to SharePoint and trying to get my head around this. I have a simple Web Part project. I also have a custom Data layer project that uses the Microsoft Enterprise Library for data access. In the Web Part project, I am adding a reference to the Data layer project's assembly. I specified in the Package of the Web Part project that I want my Data layer's assembly to be deployed. I can verify this works by using standard ADO.NET classes and not the custom MS library. If I deploy to the SharePoint server (which I have 100% access to) using the Enterprise Library, I get the error message:
"Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Data"
What steps do I need to take to ensure this project and all future projects on the server can easily gain access to the Enterprise Library for data access?
Thanks!
You did everything correct until a certain point: Deployment.
When deploying external DLLs, which shall also be put into the GAC or somewhere else, you need to package them with the WSP aswell. This has become very easy with Visual Studio 2010:
Open your Package
Click on "Advanced" (on the bottom)
Add your external DLL and maybe even SafeControls for the web.config

Error publishing workflow in SharePoint 2010

When publishing a workflow in SharePoint 2010 Designer I received the following error.
Errors were found when compiling the
workflow.The workflow files were saved
but cannot be run.
Check For Errors indicated the workflow was fine
The error was caused by Alternate Access Mappings not being configured correctly.
I was accessing the site using the url http://mysharepoint.mynetwork.local, however alternate access mappings were only configured for http://mysharepoint and http://localhost
Once I added an alternate access mapping for http://mysharepoint.mynetwork.local it published fine.

Resources