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.
Related
I use VS2010 on Server 2008 R2 with Sharepoint 2010 Foundation.
I have created a custom master page following instructions from here: http://msdn.microsoft.com/en-us/library/gg447066.aspx (activating my custom page as feature), and was delighted with the results. But as soon as I changed the images and attempted to deploy them through VS2010, I noticed that my changes were not showing in the page (which was still showing the old images).
Useful observations:
It's a Sandboxed solution.
I checked that wsp is built with the new images, and so it was.
When I retract my solution, I also go to Master Page Gallery, and
delete my custom master page from there to make sure I start from
scratch. No difference.
My SP Designer does not give me an option to "revert to site
definition".
My "Look and Feel" section in central admin does not offer a
"reset to site definition" option.
Checking "CustomizedPageStatus" property of the SPFile for my master page shows that it's set to "none", and indeed, calling RevertContentStream throws an exception. This indicates it may not necessarily be the unghosting issue.
Does anybody know where my images get deployed to, and what the cause of this problem may be? The "Deployment Location" property does not lead to the correct location (in fact, I can't even see my Feature's folder). Could it be something to do with the way variables in the path - {SharePointRoot}\Template\Features{FeatureName}\StyleLibrary\Branding101\Images\ - are parsed?
I am new to Sharepoint, so all and any help would be much appreciated.
Since this is a Sandboxed solution, everything gets stored in the content database, accessible through SharePoint Designer 2010. In SP Designer, open the site you are working on, then look under "All Files" in Site Objects: that's where I found my masterpages, images, etc.
Deployment paths (displayed in module properties in VS2010) are just red herring, as no deployment to the file system itself takes place. Hope this helps somebody else!
Apologies if this has been answered, but I could not find a similar question:
I am developing a webpart for MOSS 2007. I am using WSPBuilder to built a visual webpart (ascx) and everything works fine, but the development/debug cycle is just painfully slow, so I'd like to know if it is possible (without being too painful) to develop the user control faster using an .Net Web Application project with all of the nice F5 debugging, then import the final product into my SharePoint visual webpart.
The user control interacts with a LOB system (SQL) and does not reference the SharePoint API at all. (The reason I am building this as a webpart is because I don't need another web app to run this one page, so putting it into a webpart on a new webpart page on my existing site is the best solution IMO.) I would obviously need to import (reference?) my data access classes into my "temp" web app, but think that would not be too much trouble.
I realize this will be extra effort to get this set up, but am thinking the payoff will be reduced development time of the actual user control using a little web application vs having to use the compile/build WSP/deploy WSP/reset ISS/test/make a change/repeat cycle that MOSS requires. (I guess SP2010/VS2010 has spoiled me with the native SharePoint tools available.)
Update:
I have successfully built a simple web app with one page and loaded up my UC on the page. (I had to comment out all of the Sharepoint Import and register statements that WSP Builder added to the UC for me when I created the webpart.) I added references to my utility classes (which I left in the obj\Debug folder in the original SharePoint project). It took me a while tinkering with everything to get it to work, but the steps ended up being pretty simple and I think I can replicate the steps quickly for future projects. Once it was set up, I was able to rapidly design the UC and build in the UC functionality using the typical F5 debug cycle. Unless someone can show me why this is not a good idea, I plan to repeat this for future projects! Thanks to everyone for thier input.
.
Update 2
Well, I am not sure what I did but moving the UC back into SharePoint proved to be troublesome. The first time I did it, I spent several hours getting it to work in SharePoint, making me question whether it was worth it. However, I am stubborn and tried it again. This time, I only copied and pasted the markup below the "header section" (the part with all of the <%# . . . %> statements) in the ascx file and everything went perfectly. I think I must have changed something inadvertantly the first time. I think I will continue this pattern as it is so much faster to build and test the UC in an ASP.NET web app. (Again, this only works if you are not referencing the Sharepoint API anywhere in the UC.)
The answer here is the SmartPart. It is perfect for just the scenario you are describing. Very easy to create a Usercontrol using "vanilla" ASP.NET and have it work as a webpart in SharePoint. I've outlined the steps to migrate from ASP.NET webpage to statically bound SmartPart on my blog.
What you intend to achieve is surely a nice idea.
Just remember to strong name your user control, drop it in your Server's GAC, update SafeControls section of your SharePoint 80's web.config.
All these setps are one off, after each successive builds (of your web control), you have to just deploy the control (used forcede deploy) in GAC and reset IIS.
You can add this control to toolbox in VS by selecting 'Choose Items' and selecting ther assembly you just deployed.
In addition you can create a test ASP.NET page to test the functionality of your control.
I'm using Visual Studio 2010 to develop a SharePoint Server 2010 solution. Part of this includes custom Page Layouts, but when editing them, intellisense is completely broken, since Visual Studio doesn't appear to know how to handle them. Here's what I've done:
Created a new blank solution
Right-clicked on the solution and created a new "Empty SharePoint Project"
Right-clicked on the project and created a new "Module"
Renamed sample.txt to MyPageLayout.aspx or created a new ASPX Web Form
At this point, intellisense for the new Page Layout is broken. It gets even worse with tools like ReSharper installed. Also, things like "Format Document" will break the Page Layout (by for example changing asp:Content to asp:content)
What I've tried to get intellisense working:
Added a Web.config from a standard Web Application Project to the root of the SharePoint Project - made no difference.
Added the ProjectGuid for a Web Application Project to the SharePoint project file - broke the project.
Is there any way to get intellisense, and the rest of the support Visual Studio can offer for Web Forms, available when developing SharePoint 2010 Page Layouts?
I have followed your post to some extent.
Using VS2010 (On an x64 machine)
Create a blank SharePoint solution. (this properly combines your #1 & #2)
Add a module (in SharePoint a module is like a folder or resource container)
added a new class to the module (intellisense present)
Added a new webpart to the module (intellisense present)
added a user control to the project designer works and (intellisense present)
I believe that you should consider creating true server or visual web parts. This will have a harder learning curve but will pay with dividends in the future. You will be able to package and deploy your solution again or to another server/farm. Aspx pages can be added and manipulated by the dreaded SharePoint designer. In 2010 the theory is that those designer mods can be packaged and deployed.
I work in this environment every day and the best advice I can give is to embrace the SP object model and do 'it' the sharepoint way. Don't try to force SP to be something its not. :)
This is probably not the solution you are looking for but it's the best thing I found for SharePoint development.
In your solution, create 2 projects :
1 SharePoint Project (empty or not)
1 ASP.NET web application project
Develop all your UI (aspx pages, ascx controls, etc.) in your ASP.NET project and create post-build steps that will copy the pages and controls to the appropriate folders in your SharePoint solution.
That way, you will benefit from all the features of web development in visual studio and it will be very easy to deploy as well. It is a bit of a time investment at first, but it is well worth it if you have any considerable amount of logic to implement in your aspx pages.
This blog post documents what you need to do.
you can add an intellsense to pagelayouts by closing the page and simply reopen it from
file->openfile->your file page layout path
Or you can directly "Right Click" on the file you want to open from the Solution explorer and then select "Open" : you'll get the Intellisense !
i create a website on my local machine but i can't add webpart to web page, it don't rise any error but th webpart don't display to the page. anyone help me.
Thanks
I know this is an old question, but it's ranking high in Google results, so I figured I'd answer it anyway.
Make sure you're not running any code in the layout page's codebehind that calls and then closes SPContext.Current.Web. I had this exact behavior and that was the culprit
To test, add a different web part to a default page layout. If it adds, then it's either your web part or your code behind. If you can't add any web parts to your custom layout, it's your code behind. If it's just your web part, it's your web part.
Remember, SPContext.Current.Web returns a reference to the current SPWeb object. SharePoint will close the object itself when it's done, and closing it early can cause "unpredictable behavior."
We had the same problem with Firefox some time ago, but the problem disappeared when we installed SP2 for SharePoint 2007. The only thing that surprises me is that you also have the problem with IE.
I am developing publishing site. I have some layouts that are pre-populated with web parts and have a problem when I need to make some change on the layout.
Deployment succeeds but I still see old version. If make I change in SP Designer it is reflected OK but not if the change is done by the feature that is being deployed.
It looks like after I deploy particular layout any site collection in that web application will have the first version.
I have tried deleting complete site, all the pages, layouts and nothing happens, after deployment I still see old layout.
Current solution for this problem was that I take new virtual image and start with clean machine.
Real problem is how to solve this on clients installation without reverting to clean machine. There will be some bug fixes and I will have to send new WSP file with some changes in layout.
Is there any way to force SharePoint to use newly deployed layout and not some old Unghosted version?
If the layouts are without web parts I don't have this problem.
Update
I am using default "Publishing Portal" and deploying layouts using features. For development I am using VSeWSS 1.3.
tried in SharePoint designer to detach page from layout and attach it again but still no results.
Since you are using VSeWSS, you can execute your own code upon feature activation. So try writing an SPFeatureReceiver that will call SPWeb.RevertAllDocumentContentStreams() to reghost directly after feature activation on the web(s) in question.
If this doesn't work, then the problem isn't about ghosting, maybe it's about Orphans then. But try this first.
If it's a feature that you are deploying you have do deactivate the feature and activate it after deployment again. And don't forget to do an IISRESET or an AppPool recycle.
If your new site collection has the first version of the layout make sure that it is really your new feature version that you are activating.
Try to reject your solution first and add the new one after that.
Are you using Site Definitons or Site Templates? If you are using either of these it may not update after initial provisioning.
Try completely retracting and deleting the solution from central admin, resetting AppPools and then redeploying the solution.
Make sure your element manifest for your feature specifies that existing files should be overwritten.
Looks like some folks have had problems with layouts too...
See http://msdn.microsoft.com/en-us/library/ms459213.aspx
If you are developing new sitedefinition, you can attach your new layout in the onet.xml file by using the property, i hope it will help you
-->