I have only ever deployed web parts from development by clicking F5. Now, I know I have to have a manifest file, feature file, etc and it all goes into a wsp file. I understand the wsp file is what gets added to Central Admin.
So my problem is this. I have found lots of sites that show how to use WSP Builder, but they don't seem to show how/where I add my web part to the WSP Builder project. My understanding is that somehow I should be able to use WSP Builder to create a wsp file containing my already-developed web part.
There are only two approaches that I see would work.
I create a WSPBuilder project (like all the how-tos on WSPBuilder show), then I assume I would somehow add my web part to that project - although I don't know how.
In my web part project, create WSPBuilder -> Build WSP. I have done this, and when I run stsadm on the resulting wsp file, I get it in Central Admin, but its not added to my Site Collection Features or my Web Part Gallery.
Can someone please explain this to me like I am a 6 year old? If you point me to another site, there is a good chance I have already seen it, so then I would ask you point me to the specific lines that tell me how to get my already existing web part packaged into the wsp.
To create a new web part feature with WSPBuilder:
Right-click on the name of your WSPBuilder project in Visual Studioand click Add, New Item.
Select WSPBuilder from the tree on the left and choose Web Part Feature from the list on the right of the dialog.
Enter the title of the web part feature and click OK.
In the dialog that appears enter the title, description and scope and click OK.
Your feature will now be created. You will then need to merge your existing web part code into this feature and configure its XML files.
Read this walkthrough by Tobias Zimmergren for more information. There is another walkthrough here.
Alex, got the right path to solve it. I think the small exception here is that wrongly spelt Add New Item instead of New Project.
Related
Now it's my turn to ask this question..
I've been reading about setting up an umbraco project in VS2012 but i really don't know if im doing it worng, or if it's just not possible..
Is it possible to setup an umbraco project in VS2012 with ability to add templates, and documenttypes and create sites and more with VS2012 without using the umbraco admin tool? :-)
Yes, in fact, only 2 minutes ago I finished checking in a brand new project, a VS2012 solution housing an Umbraco v6 website.
My solution/directory setup is particular, and no doubt yours is too, but the bottom line is that the Umbraco is just an ASP.NET website, so you can add it to a solution using thew "Add existing website" option, to the root or subdirectory of your will.
Then you can use the Solution Explorer to edit files such as those in the css, masterPages, and macroScripts folder etc.
One note of caution would be this. When using 'Umbraco scripts' (i.e. Razor scripting files and such) then, when created in the Umbraco UI, a calling Macro is also created (by default, though there is an opt-out) and (historically) some database goings-on, and so in the case of scripts, I think it's always wise to initially create them using the Umbraco UI.
Other than that, are you having a specific problem, as I don't see you point one out?
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!
I have an event handler feature that I've built for sharepoint 2007 and have deployed by moving the DLL to the GAC and creating Feature.xml and Elements.xml in the necessary folder and then installing them using the stsadm commands. I'm looking to avoid doing all this and instead have a WSP file that I can run to install the feature automatically in a production environment.
Thanks
Here's how I would proceed to convert your unmanaged items into a managed solution package in Visual Studio 2010:
Create an "Empty SharePoint Project".
Set the deployment target. In Solution Explorer, click the project node and look at the Properties pane. Set the Assembly Deployment Target property between GlobalAssemblyCache and WebApplication. In this case, we'd leave it as the default GlobalAssemblyCache.
Note also there's a handy property called Include Assembly In Package. This is used to exclude your default project assembly from the output package. Why do you need this? If your project contains no code: for example, you're just bundling up some third-party DLLs for deployment.
Replace your SharePoint DLL references. Follow the steps in Adam Macaulay's article to remove the v14 DLLs and add back the v12 DLLs.
Add an Event Receiver item. Right-click your project and point to Add > New Item... and select "Event Receiver". Give the event receiver a proper name and click Add.
Configure the Event Receiver. Visual Studio will connect to your (2010) SharePoint instance, then prompt you with a wizard to walk you through what events you want to handle and for which item types. The end result is an Event Receiver item in your solution with a stubbed-out class that overrides the proper methods, as well as an Elements.xml file that is configured appropriately. If you have both of these files already, you don't really need to complete the wizard "truthfully"... just select the first option, click Finish and let Visual Studio create the Event Receiver and corresponding Feature.
Add your code logic. In Solution Explorer, expand your Event Receiver node to reveal the .CS class and the corresponding Elements.xml. Copy the contents of your existing files into those locations.
Configure the package feature. In Solution Explorer, expand the "Features" node and locate the default feature (Feature1.feature). This was created when you added the Event Receiver item. For clarity's sake, rename the feature to something logical, then double-click it to open the feature in design mode. You should see your Event Receiver has already been added to the right-most pane ("Items in the Feature"). Were there others, you could selectively add/remove items from the feature. Here is the place you set the feature scope between Farm/Site/Web/WebApplication.
Also importantly, while in the Feature designer, notice the Properties pane has a wealth of additional options to set on the Feature. These can't be accessed any other place, so keep in the back of your mind that is where to find them.
Lastly, if you click the Manifest tab at the bottom of the designer, you can preview what the feature manifest will look like. The manifest can be manually edited if need be (effectively disabling the designer), but I have yet to find something I need to do that I can't configure via properties.
Configure the overall package. In Solution Explorer, expand the "Package" node and locate the default package (Package.package). Just as for features, double-click the package to open it in design mode. This is the same UI that features use, allowing you to pick which features will be part of this package. Your event receiver feature should already be added to the right-most pane ("Items in the Package").
Again, same as features, while you're in Package design mode, the Properties pane will make available certain properties that can't be edited elsewhere. Most notably, it is here you should clear the value out of SharePoint Product Version.
Also, we have the same manifest preview available to us via the Manifest tab at the bottom of the screen. This is handy for checking things like SafeControl entries (if you need them) and the like. The Assembly entry should reflect the correct deployment target (in this case GlobalAssemblyCache) that was set on the project.
Finally, the Advanced tab allows you to specify additional assemblies/SafeControl entries to the package, which is helpful if you're bundling up additional DLLs to the default project DLL.
Build your project. Obviously we want to make sure it compiles!
Test the deployment. When I test, I deploy to my 2010 instance first (because it's handy) and double-check that everything has been installed as I expected: DLL in the correct place (BIN/GAC), appropriate Web.config entries created, feature installed at the right scope, feature activates properly, etc.
Package the solution. Point to your Build > Package menu item. The WSP will be placed in the appropriate output folder for the active configuration. Test deploy to your SharePoint 2007 instance.
Check out "Build a SharePoint 2007 Web Part with a Visual Studio 2010 Visual Web Part Project" written by Adam Macaulay. I used this as a reference when I wanted to do the same, and the methodology works great. I've successfully converted a lot of our Visual Studio 2008 projects to 2010 projects, while maintaining compatibility with SharePoint 2007 environments.
I will make one suggestion: if you don't absolutely need the Visual Designer for your web part (i.e. your web part's output is made programmatically), then using the Visual Web Part template adds extra "junk" to your solution which I dislike.
Rather, in step 1 create instead an "Empty SharePoint Project", then right-click on your Project in the Solution Explorer and point to Add > New Item... and select "Web Part" (not "Visual Web Part"). You don't end up with the ASCX control and you can ignore the parts of Adam's tutorial that deal with updating the Register declarations.
This also has the added benefit of capturing the correct name for the web part files up front, so you don't have to rename a bunch of "VisualWebPart1xxx" files.
I need to transfer a reusable Workflow from the stage env. to the prod.
The workflow is associate to a list, so the list id is stored in the workflow.
Is it possible to transfer the workflow and change the list id to the list name with Visual Studio? (We have no SharePoint Designer access to the prod. env.)
Short answer: No
I tried several hours to fix a reusable workflow, which same as yours was associated with a specific list - I switched systems and the GUID changed --> Workflow was broken.
You can give it a try and rename the MyWorkflow.wsp to MyWorkflow.cab and extract that somewhere. The workflow files are XML based hence you can edit the associated list GUID with your favorite editor. Now you need to package your edited file back into a cab file, rename it to wsp and you can give it a shot. I tried exactly that and resented to just "re-clicking" (as it's SPD) my workflow (two screens come in handy here).
That's what I call "reusable" workflow... Next time do not associate your reusable workflow with anything to keep it reusable.
I would recommend creating an Content Type in a Feature and then base your list and your Reusable Workflow association on that Content Type. We had a project in December where we successfully used this method. I saved a Reusable Workflow as a template. I then deployed the Content Type solution package and the Workflow solution package to another environment. Worked like a charm.
There are tow alternatives for deploying workflow regardless the assigned content types
It is very simple just do the following:
Alternative One
Save the workflow as template
Go to the following path in your site
http://your_server_Address/SiteAssets/Forms/AllItems.aspx
Download the file as WSP
Go to the following URL
http://your_Target_server_Address/_catalogs/solutions/Forms/AllItems.aspx
Upload the WSP, and activate the solution
Go to the site settings, then Site Actions, then Manage site features
Activate the feature that is related to the workflow
If you click workflows under site administration you would be able to see your custom reusable workflow
Alternative Two
Save the workflow as template
Go to the following path in your site
http://your_server_Address/SiteAssets/Forms/AllItems.aspx
Download the file as WSP
Open your visual studio
Click add new project
Under SharePoint choose 2010
Choose Import reusable work flow
Follow the wizard
Project will be created and can be deployed
Note : Make sure your workflow is reusable and that it has no errors
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 !