Home > sharepoint, webpart, wspbuilder > Developing SharePoint WebParts using User Controls and Web Applications

Developing SharePoint WebParts using User Controls and Web Applications

If you’ve read my blogs before, then you probably know I am a fan of WSPBuilder (http://www.codeplex.com/wspbuilder). I like the intuitive nature and flexibility of the product. It really helps with the deployment aspects of SharePoint features and functionality. However, in the end, it is really just a structured way to create a deployment/feature project that will create the wsp install file for SharePoint. It really doesn’t help much when building UI functionality. For example: if you want to build a Web Part in SharePoint, you still have to build the Web Part code out programmatically (instead of using the WYSIWYG features of Visual Studio). The same issue comes up with building master pages, application pages or anything that requires html and a code behind.

In this article I am going to show you how you can utilize the flexible nature of WSPBuilder, ASP.Net Web Applications and post build scripts in order to utilize WSPBuilder as your deployment project for your UI. 

Solution Overview

SharePoint is a dynamically generated website that pulls information out of a database. It also utilizes files on the server and uses those files as templates or actionable files. The combination of these static files on the server and the information in the database creates the web page we see. This architecture is what allows us to create pages, add webparts, modify navigation, etc… all within the SharePoint site itself.

So, when developing against SharePoint, we need to deploy files to this static place on the server and register the files in the database. This static place on the server is called the 12 hive. It is usually found at: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12. A lot of stuff goes on in the 12 hive. You have the templates for the website, images, themes, etc… You also have very special items called Features. Features allow us to deploy custom functions to SharePoint and then activate/deactivate them at our leisure.

WSPBuilder allows us to “mimic” the 12 hive, within a Visual Studio project. As long as you have the same 12 hive structure setup, it can create the SharePoint deployment file (i.e.: the wsp). You do not need WSPBuilder to create wsp files; you can do the same thing by building extra files in your solution called manifest.xml and ddf files. However, for rapid application development, it is easier to use a third party solution like WSPBuilder because it creates those extra deployment files for you.

While WSPBuilder is a great tool to help us build the deployment files, it is not a web application project in Visual Studio. Web application projects help us build code behind and designer files for our server side controls.

Thus, the ideal solution for building UI elements in SharePoint consists of:

  1. ASP.Net Web Application project to build the UI elements
  2. WSPBuilder project to create our deployable wsp file

The ASP.Net Web Application project will contain the UI elements (such as User Controls). The build process will move the appropriate elements from the ASP.Net Web Application project to the WSPBuilder deployment project. Then the deploy will move the files from the wsp to the SharePoint Server.

Deploy

The key to this solution is seperation of concerns. You should build all UI related functionality in the ASP.Net Web Application project. All SharePoint specific functionality (ex: features), should be built in the WSPBuilder project.

 

Create the WSPBuilder deployment project

  1. Create your project in Visual Studio (File – New – Project)
    • Choose the WSPBuilder project. I am utilizing the one under c# for this example.
    • Give it a good name. I am using DemoProject for this example.
    • Make sure it creates a new solution when creating the project.
  2. Add a folder under the 12 folder called “Template”.
  3. Add a folder under the Template folder called “LAYOUTS”.
  4. Add a folder under the Template folder called “FEATURES”.
  5. Add a folder under the Template folder called “CONTROLTEMPLATES”.
  6. Add a folder under the project called “GAC”.

Note: The “GAC” folder in WSPBuilder is a special folder. We can place external dlls in this folder the the resulting WSP will deploy those dlls to the GAC for us.

DemoProject

 

Create the UI project

As I mentioned in the beginning of this article, the point is to create our UI elements in an ASP.Net Web Application project. So, we need to create another project, in the same solution, so that we can develop our UI elements.

  1. Create the UI project (File – Add – New Project)
    • Choose the ASP.NET Web Application Template. I am utilizing the one under c# for this example.
    • Give it a good name. I am using DemoProjectUI for this example.
  2. Delete the Default.aspx
  3. Sign the project (this is because we are going to deploy to the GAC)
    • Go to the properties (right-click the project and choose properties).
    • Go to the Signing tab.
    • Choose “Sign the assembly”.
    • Under the “Choose a strong name key file” – choose <New>
      • Give it a strong name – I usually use the name of my project (for example: DemoProjectUI).
      • Uncheck “Protect my key with a password”.
  4. Add in the post build commands
    • Go to the properties (right-click the project and choose properties).
    • Go to the Build Events tab.
    • Add the following into the post build section:
      xcopy "$(TargetPath)" "$(SolutionDir)DemoProject\GAC\" /Y /s
      xcopy "$(ProjectDir)*.ascx" "$(SolutionDir)DemoProject\12\TEMPLATE\CONTROLTEMPLATES\" /s /Y /R

Let’s recap what we did in the steps above. First we created a WSPBuilder project called DemoProject. This is our deployment project. It will create wsp files that we can deploy to SharePoint. Then we created an ASP.Net Web Application project called DemoProjectUI. This is where we will create all our UI elements. This will allow us to create user controls with html and code behind files. Lastly, we made sure that we moved the dll and ascx files, from the DemoProjectUI project, to the appropriate place in the DemoProject project.

 

Create a Web Part

Our next step is to create a Web Part. As anyone who has developed in SharePoint before knows, Web Parts are complete code files. They are not the html with code behind files we are used to when developing in ASP.Net. Some people are fine with developing Web Parts completely programmatically. However, it is much easier to create UI elements when you have WYSIWYG editors, html and code behind.

One way to get the normal ASP.Net web development experience, when developing Web Parts, is to use the SmartPart. The SmartPart is a very clever Web Part, developed by Jan Tielens, which can render .Net user controls in Web Parts. I really like the SmartPart, especially for people learning to build SharePoint Web Parts as user controls. However, I like more control over what I do and there are some limitations to the SmartPart. It is not my intent to go over those limitations in this article, but you can read them here: http://weblogs.asp.net/erobillard/archive/2008/03/04/what-to-know-about-smartpart-and-loadcontrol.aspx

In the end, you can accomplish the same thing as the SmartPart using the “LoadControl” method in .Net. Thus, this article will show how to create a Web Part, which will load the user control from our UI project.

  1. Create the Web Part using WSPBuilder
    • Right-click on the DemoProject project
    • Go to Add – New Item
    • Choose WSPBuilder – Web Part Feature
    • Give it a good name. For this example I am going to use DemoFeature
    • A popup will come up with Title, Description and Scope. Since we are developing a Web Part, you must choose “Site” for the scope. This is because we need the Web Part to deploy to the Web Part gallery of our Site Collection.

    Notice that WSPBuilder did two things for you:
    – It created the feature in the features folder
    – It created the Web Part code in a folder called WebPartCode

  2. Modify the Web Part code to use “LoadControl”
    • Open up the DemoFeature.cs file in the WebPartCode folder
    • Remove the MyProperty property and attribute for now. This is just WSPBuilder showing you how you can use properties. We aren’t going to use them for this demo.
    • Find the CreateChildControls method and find the comment that says “Your code here…”
      • Remove the line under it.
      • Replace it with this: this.Controls.Add(Page.LoadControl("~/_controltemplates/DemoControl.ascx"));

      Your CreateChildControls method should look like this:
      protected override void CreateChildControls()
      {
          if (!_error)
          {
             try
             {
                base.CreateChildControls();
                this.Controls.Add(Page.LoadControl("~/_controltemplates/DemoControl.ascx"));
             }
             catch (Exception ex)
             {
               HandleException(ex);
             }
          }
      }

  3. Add the control to the UI project
    • Right-click on the DemoProjectUI project
    • Go to Add – New Item
    • Choose Web – Web User Control
    • Give it a good name. For this example I am going to use DemoControl.ascx

Now, when you build your solution, the DemoControl.ascx will move to the ControlTemplates folder in the DemoProject project. The SharePoint Web Part will look for the control by using the _controltemplates path.

Note: SharePoint can find any control in the ControlTemplates folder by using the _controltemplates path because of a mapping it creates in IIS. SharePoint maps the _controltemplates path to the servers 12 hive at 12/Template/ControlTemplates.

 

Utilizing the Code Behind

We now have our basic solution setup. We have our UI project and can build our user control there. We have our WSPBuilder deployment project that will create our SharePoint install file. But, we aren’t ready to deploy just yet. We still need to tell our user control how to talk to its code behind. Because we are utilizing the GAC for our assemblies, we need to put a fully qualified domain in our ascx file. There are a couple of techniques for figuring out this fully qualified domain. What I like to do is deploy the project and go to the GAC to get the properties.

  1. Deploy the WSP, so that the assembly gets added to the GAC, so that we can pull out the assembly information.
    • Right-click on the DemoProject project
    • Click WSPBuilder – Build WSP (wait for it to finish)
    • Right-click on the DemoProject project
    • Click WSPBuilder – Deploy WSP (wait for it to finish)
    • Get the assembly information from the GAC
      • Usually found at C:\Windows\assembly
      • Right-click on the DemoProjectUI assembly and click properties
      • Note the public key token and version ( I suggest copying the public key token at this point because we are going to use this information in the next step).
  2. Add the assembly information to the ascx
    • Go to the DemoControl.ascx file in the DemoProjectUI project
    • Add an Assembly reference as the first line in this file. Below is an example. However, you cannot copy this example. Your assembly reference must have the correct information about your assembly (including your public key information).


<%@ Assembly Name="DemoProjectUI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=772ab5f02712b819"%>

 Now we are ready to test our solution!

 

Deploy the Solution

Now that we are finished setting everything up, we can deploy the solution. This is real easy with the use of WSPBuilder as long as we are developing on a SharePoint server.

Note: Please make sure you have a web application and site collection setup in SharePoint before doing the following steps. When you deploy the WSP solution, it will deploy to all web applications on your development server. Thus, the web application must exist before you deploy.

  1. Right-click the DemoProject project
  2. Click WSPBuilder – Build WSP (wait for it to finish)
  3. Right-click on the DemoProject project
  4. Click WSPBuilder – Deploy WSP (wait for it to finish)
  5. Open up your SharePoint site.
  6. Note: if you go to the SharePoint site at this point and it says “Server Not Available”, then just keep refreshing the page until it shows up. The WSP install recycled the application pools because it needs to every time a dll in the GAC is added or modified. It sometimes takes a few seconds for this process to finish.

  7. Go to Site Actions – Site Settings
  8. Go to Site Collection Features
  9. Activate the DemoFeature
  10. Go back to the site
  11. Go to Site Actions – Edit Page
  12. Click “Add a Web Part” in one of your web zones
  13. Find your WebPart. It should be under “MyGroup” unless you changed the group name in your feature. The elements.xml file in the feature folder of the DemoProject lets you configure this information. I
  14. Add your Web Part to the page

At this point your Web Part is empty because we didn’t add any html or code to it. However, you solutions architecture is ready to go. Now you can go back to your User Control, do your development, deploy the solution and it will show up on your page. Let’s give it a try.

  1. Go to the DemoProjectUI project
  2. Open the DemoControl.ascx
  3. Put a label tag on the control
  4. <asp:Label runat="server"  ID="test" />

  5. Go to the code behind (i.e.: DemoControl.ascx.cs)
  6. In the Page_Load type the following
    protected void Page_Load(object sender, EventArgs e)
     {
          test.Text = "Hello World";
     }
  7. Right-click the DemoProject project
  8. Click WSPBuilder – Build WSP (wait for it to finish)
  9. Right-click on the DemoProject project
  10. Click WSPBuilder – Deploy WSP (wait for it to finish)
  11. Open your SharePoint site and see your Web Part. It should say “Hello World”.

Remember: if it says “Server Not Available”, then keep refreshing the page until the site shows up again.

Wow, that was a lot of setup just to create a user control that can render in a Web Part. But, the great thing is, you only have to do the setup once. As a SharePoint Architect, I set this up for my team and they can just concentrate on building the user controls. It runs very smooth!

Per popular demand, here is the demo solution from the walkthrough. I used Visual Studio 2008, WSPBuilder Extenstions 1.0.5 and .net 2.0 for this solution (I used 2.0 so it can work for a client of mine, it can be upgraded to 3.5 easily)
DemoProject

Advertisements
Categories: sharepoint, webpart, wspbuilder
  1. Fedrek
    May 19, 2009 at 10:11 am

    HI,
    Nice article, i have tried to use the same but MOSS throws me this exception. Will you b so nice to guide what i am doing wrong.
    Thanks

    [SecurityException: Request for the permission of type ‘Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’ failed.]
    Microsoft.SharePoint.ApplicationRuntime.SPVirtualPathProvider.GetCacheKey(String virtualPath) +43
    Microsoft.SharePoint.Publishing.Internal.CmsVirtualPathProvider.GetCacheKey(String virtualPath) +47
    System.Web.Hosting.VirtualPathProvider.GetCacheKey(VirtualPath virtualPath) +23

    • Greg Galipeau
      May 25, 2009 at 2:14 am

      Hi Fedrek,
      Sorry it took me so long to reply, I was on vacation last week.
      Anyways, “when” did you get this error? Did you get it when you were deploying the solution? If so, that error could be because of the rights you need to deploy. The user deploying needs high rights to the database. I suggest doing deployments as the farm administrator.
      If you got this message during a different step, then tell me “when” you got it and I can give you some more ideas. But, I have a feeling this has to do with “who” you are logged into your server as.

    • sara
      September 30, 2009 at 11:14 am

      Create Custom SharePoint WebParts, it is simple.
      Try this too,
      Custom SharePoint WebParts

  2. Procrustean
    May 21, 2009 at 9:41 pm

    Great article! Very helpful, since I’m learning SharePoint and figuring out its integration w/ ASP.Net.

    Thank you!

  3. May 26, 2009 at 10:52 pm

    I have also posted a very similar post on the SharePointDevWiki.com
    http://www.sharepointdevwiki.com/display/public/SharePoint+Development+with+Visual+Design+User+Controls

  4. kris
    June 2, 2009 at 4:02 am

    Hi,
    Nice article. Wondering if the same techniques can be used for creation of application and site pages. I find it to be cumbersome to muck with the XML files for feature and elements.

    Thanks.

    • Greg Galipeau
      July 15, 2009 at 8:21 pm

      Some things from this article are applicable for application and site pages. For example, you can create these in your web application project, use a code behind and move them to the correct folder with post-builds (or linked references like one of the other comments mentions). However, you will still have to muck with the XML files for the features and elements when building pages. However, application pages don’t relly on you mucking with feature files because you can move them right into the layouts folder in WSPBuilder (just make sure you have a layouts folder in your WSPBuilder project that is in the correct 12 hive location).

  5. Brent
    June 2, 2009 at 6:32 pm

    Hi Greg,

    Nice article. I was wondering if you test these User Controls in your web app before you deploy them.

    I would like to:

    1. Add a simple aspx page to my web application (DemoProjectUI in your case).
    2. Add the ascx file there and test functionality.
    3. Deploy using WSPBuilder if it’s working properly.

    However, if the feature is already deployed, I can never get the webform type to load, even though I’m rebuilding and copying the assembly to the GAC again (via the WSPBuilder menu).

    If I uninstall the feature, everything starts working as expected.

    Any thoughts? Thank you.

    • Greg Galipeau
      June 2, 2009 at 6:42 pm

      Yes, I have tested them in the WebApp before deploying them with the WSPBuilder solution. One extra step I do in that situation is add some more post build commands to the ASP.Net project. These extra post builds should be for the GACUtil and an IIS reset. The reason I do this is so the ASP.Net application utilizes the GAC like the SharePoint app will. However, I do notice some issues with that (like you mentioned).
      First thing to verify is that all your assmeblies utilize the “GAC”. Nothing in the ASP.Net environment should utilize code behinds or anything else unless they are referencing fully qualified assemblies from the GAC. I had an environment once where a developer had a test page in the ASP.Net solution and he referenced the user control. The user control was referencing the GAC, but the test page was referencing the BIN. This really messed things up.
      Second thing to check is that your IIS app pools are being recycled (this is done with the WSPBuilder deploy by default).
      The other thing I always make sure I do is stop the local web server. ASP.Net starts a local web server when you debug with it, it shows up as an icon in the lower right corner. Right-click on that and make sure it is stopped before moving to SharePoint testing.
      That is all I can think of right now. There might be something else going on with your environment, but I would have to see it to figure it out. Check the three things I mentioned above and tell me if it works.

      • Brent
        June 2, 2009 at 6:50 pm

        Thanks for the quick reply. So your build on the web application does the GAC installation?

        I wonder if the WSPBuilder “Copy to GAC” item moves all DLLs from the GAC folder over if you’re not doing a deploy.

        • Greg Galipeau
          June 2, 2009 at 6:55 pm

          I never really use the “Copy to GAC”, so I am not sure what it does behind the scene. But, you want to make sure that it recycles the app pools or does an IIS reset. Of course, the easiest way to test that is to run the command, go to your site quickly and see if it says “Server not responding” for a couple seconds before it ends up working.

          But, yes, if I set up the scenario in which I do all my testing locally on my ASP.Net project, then I let the build do the GAC installation. I like getting everything down to the least amount of steps possible to make development move quickly.

          To be honest though, I rarely set this scenario up. Usually, I create things, deploy to SharePoint and then test. I have set it up in the past because other developers wanted it. But, other than the issues you are describing, we also ran into issues around things not working the same in SharePoint as they did in the ASP.Net application because of how the two sites were configured differently. Anyways, it is just something to keep in mind when making this choice of how to setup the environment.

  6. wl
    June 3, 2009 at 2:07 pm

    I have a web application developed with VS 2003. I guess I can’t make my aspx pages to user controls. I am still new to Sharepoint, I need my web application go to SharePoint. I am still debating what the best approach is, simply rewriting it or use the WSP builder to deploy it to Sharepoint.

    Please advice.

    • Greg Galipeau
      June 3, 2009 at 8:43 pm

      There is no way “real” way to put a web application, developed outside of SharePoint, into a SharePoint page. However, you have a couple options to make the process easier:
      1. Rewrite the pages as controls and incorporate them as WebParts.
      2. Put the web pages in the layouts folder of SharePoint and utilize them as application pages. You would want to research custom application pages to do this.
      3. Use the Page Viewer WebPart and show the pages that are located on another web application in your SharePoint site. The Page Viewer WebPart is basically an iframe, so consider that when choosing this approach.

      But, in the end, SharePoint is not really meant to host web applications you build outside of SharePoint because it is a web application in itself. So, when building UI and business components for SharePoint, it is best to keep SharePoint in mind when building them.

  7. Procrustean
    June 3, 2009 at 6:48 pm

    Regarding DemoProjectUI PublicKeyToken, when promoting my codes (solution package) from Dev to Staging or Production environment, would I need to set the assembly info again?

    • Greg Galipeau
      June 3, 2009 at 8:44 pm

      No, you don’t have to do that. When you sign an assembly it gives it a unique token. So, no matter where you move the solution, the public key token will be the same.

  8. Cecil John
    June 5, 2009 at 7:21 pm

    Hi,

    Thanks very much for this tutorial. It has been really helpful.
    Unfortunately, I seem to have tried everything, but I keep getting the following error message in my deployed web part:

    DemoFeature

    Could not load type ‘DemoProjectUI.DemoControl’. ”

    Does anyone have any suggestions?

  9. June 6, 2009 at 2:34 am

    Solid article Greg.

  10. June 7, 2009 at 3:34 pm

    Greg,

    Small question, was wondering what does _error correspond to?

    Thanks,
    Jason

    • Greg Galipeau
      June 7, 2009 at 8:54 pm

      Hey Jason,
      _error is just something WSPBuilder does for you when you use it’s template to create a WebPart. It basically is just a variable that gets set to true in the HandleException method. That way, if one part of the WebPart errors out, it won’t even try running any more code.

  11. kumar
    June 19, 2009 at 7:31 am

    Hi,
    This is Kumar. i m New to MOSS but i follwed wt ur mentioned step by step but i was struck.
    when u mention step creating : Create the UI project
    Here I created ASP.Net web application and right-click the project and choose properties .
    Im not find properties it display Property Pages.
    please help me

    Thanks
    Kumar

  12. Tukaram Thatikonda
    June 26, 2009 at 3:07 pm

    Greg Galipeau,

    Thank you for this article!

    I faced this issue even earlier with manual deployment of user control web part –
    1) The web part page throws an error that says –

    Could not load type ‘DemoProjectUI.DemoControl’.

    2) To fix this issue, I manually added the 2 lines in the web.config file of the web application –

    and deleted the line from the DemoControl.ascx file

    It works now!

    I don’t see WSPBuilder solves the manual steps.

    Your questions –
    1) Am I doing something wrong or some other setting is causing this behaviour? Do I have to manually make changes to the web.config file everytime?

    2) Is there a way in the WSPBuilder to control the settings in the manifest.xml file? I believe, the tool creates it automatically. How can I modify the manifest.xml file to tell WSPBuilder to also add the additional above 2 lines in the web.config file?

    I appreciate your response or some guidance!

    Thank you!

  13. Tukaram Thatikonda
    June 26, 2009 at 3:13 pm

    Greg Galipeau,

    Thank you for this article!

    I faced this issue even earlier with manual deployment of user control web part –
    1) The web part page throws an error that says –

    Could not load type ‘DemoProjectUI.DemoControl’.

    2) To fix this issue, I manually added the 2 lines in the web.config file of the web application –

    [add assembly=”DemoProject, Version=1.0.0.0, Culture=neutral, PublicKeyToken=7e798f53875aedf6″ /]
    [add assembly=”DemoProjectUI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=425f0e1e6f89c401″ /]

    and deleted the line from the DemoControl.ascx file

    [%@ Assembly Name=”DemoProjectUI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=425f0e1e6f89c401″ %]

    It works now!

    I don’t see WSPBuilder solves the manual steps.

    Your questions –
    1) Am I doing something wrong or some other setting is causing this behaviour? Do I have to manually make changes to the web.config file everytime?

    2) Is there a way in the WSPBuilder to control the settings in the manifest.xml file? I believe, the tool creates it automatically. How can I modify the manifest.xml file to tell WSPBuilder to also add the additional above 2 lines in the web.config file?

    I appreciate your response or some guidance!

    Thank you

    • Greg Galipeau
      June 26, 2009 at 3:28 pm

      I am not sure why the assmebly reference in the ascx file didn’t work and the assembly reference in the web.config did work. Those two techniques should work exactly the same. I always use the ascx technique because it is easier.
      To deploy web.config file changes in SharePoint you actually have to use the API.
      There is an object called WebConfigModifications (you can’t make web.config changes through the manifest.xml). You can package it up in a feature to make web.config changes. It is a little more difficult to do things this way, so I would suggest trying to track down why the assembly reference in the ascx didn’t work.

      • Tukaram Thatikonda
        June 28, 2009 at 5:29 pm

        Greg,

        I got it working by adding the fully qualified name to the inherits attribute –

        [@ Control Language=”C#” AutoEventWireup=”true” Codebehind=”DemoControl.ascx.cs” Inherits=”DemoProjectUI.DemoControl, DemoProjectUI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=425f0e1e6f89c401″ %]

        This works for VS.Net 2005 web part (.Net 2.0) but it fails for web part built with VS.Net 2008 (.Net 3.5).

        Question – Is your article targeted to run with VS.Net 2005 (.Net 2.0) or VS.Net 2008 (.Net 3.5)?

        Many Thanks!

        • Greg Galipeau
          June 28, 2009 at 7:18 pm

          Interesting, I am not sure why the assembly reference didn’t work compared to the fully qualified inherits. I have used both approaches before in the past (so they both should work). Recently, I’ve been using the assembly approach a lot and have never had an isue.

          As for your question about VS2005 (2.0) vs VS2008 (3.5), there should not be a difference. Microsoft didn’t mess with this stuff in the two different versions of the framework. So, there shouldn’t be a difference. I use both currently (I have one project in 2.0 and one project in 3.5 right now) and they are both working. So, it might be something else going on there making the one not work. Sorry I couldn’t be more of a help on this issue.

  14. Goddard
    June 29, 2009 at 8:41 pm

    Tukaram Thatikonda,

    I have the same exact issue. I tried removing the reference in the usercontrol but still no luck. I have not tried building for 2.0 yet but will give it a shot and see if that works. SharePoint web control development = never any fun. I can’t wait until they have the 2010 user control web part development and forms design and development integrated into visual studio…. 10 years later. WOW, that’s insane.

  15. Goddard
    June 29, 2009 at 8:46 pm

    Is the error Unable to get solution id from manifest: Unable to extract manifest.xml from: D:\projects\pubsvn\trunk\WebPartsCore\WebPartsCore.wsp maybe related to the above issue?

  16. Goddard
    June 30, 2009 at 7:53 pm

    So here’s the user control now:

    It seems to be working fine now. I had to do an IIS reset. The assemblies are in the web config as safe so I am not sure if this is helping or not but I’m leaving them for now.

  17. Goddard
    June 30, 2009 at 7:53 pm

    Assembly Name=”WebPartsUI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=92b562edf98b3480″

    Control Language=”C#” AutoEventWireup=”true” CodeBehind=”UserRegistration.ascx.cs” Inherits=”WebPartsUI.UserRegistration” %>
    <asp:Label runat="server" ID="test"

  18. July 3, 2009 at 9:30 am

    Rather than copying files around with Build actions, you can instead use the Add as Link option when adding the .ascx file to the Control Templates folder. This ensures that you don’t have any issues with using the wrong version of the .ascx file as it only exists in one location.

    See item 10 in the section Creating the ASP.NET User Control within the SharePoint Guidance package for more details: http://msdn.microsoft.com/en-us/library/dd206945.aspx

    • Greg Galipeau
      July 3, 2009 at 1:05 pm

      Thanks for the thought. I like the idea of using Add as Link. It actually brings up an interesting dilema in my mind. While Add as Link seems very clean. The post-build options allows me to set the entire project up once and then everything just works for the other developers (i.e.: anything in the control template folder gets moved to the right place). The Add as Link forces you to do this every time a new ascx control is added. So, I kind of like the post build option just so I can take away one more steps from the actual developers. Of course, this assumes you are setting up a large project that multiple developers will work on. But, I also see your point with multiple files. It isn’t usually that big of an issue, because they get moved every time you build your WSP (i.e.: WSPBuilder does a solution build each time, not just a project build). But, while it “shouldn’t” be that big of an issue, things always happen in development 🙂

  19. Goddard
    July 7, 2009 at 10:53 pm

    Is there any way to get the typed reference to the user control after I load it? I’d like to use the properties now 🙂
    Control productListControl = Page.LoadControl(“~/_controltemplates/ProductList.ascx”);

    The minor issue is that the productListControl reference isn’t typed so the public properties do not show. I am sure there must be some way to set properties using an index of some sort but I wanted to see about a cleaner way.

    I tried adding a reference to my web project in the web parts loader project but the strongly typed controls don’t show up, nor does the namespace.

    Any thoughts? Thanks again!

    • Greg Galipeau
      July 7, 2009 at 11:49 pm

      I am pretty sure you can just cast your control to the type you want and then set the properties. However, if that doesn’t work, you can always build your own LoadControl method that takes in parameters and sends them to the constructor of the user control. This technique is shown here in Sahil Malik’s blog: http://blah.winsmarts.com/2006/05/20/loadcontrol-a-usercontrol–and-pass-in-constructor-parameters.aspx . I use this technique a log. I usually create a base control for all my controls and put this method on the base control. That way any of my usercontrols can utilize it.

  20. Goddard
    July 8, 2009 at 12:08 am

    For some reason (most likely because the web project is ultra flakey) the referenced projects namespace and classes are unreconized. This whole process has been super messy but thank you for providing the guidence. You really have Svedberg me a ton of time! Thanks for the link on the load control technique. Pretty funny how the guys attitude is basically like all jaded sharepoint engineers. Cheers!

  21. Goddard
    July 15, 2009 at 6:23 pm

    Another nice tidbit is that you can only use .NET 3.5 code if you follow these instructions first:
    http://weblogs.asp.net/jan/archive/2008/10/10/enabling-net-3-5-in-sharepoint-2007-sites-the-lazy-way.aspx

    I also got WSP Builder working with Visual Studio 2010 Beta 1. See this thread for details:
    http://wspbuilder.codeplex.com/Thread/View.aspx?ThreadId=62447

  22. Synfyn
    August 5, 2009 at 5:42 pm

    Dear Greg,
    Thank you for this article!
    I am new to Sharepoint and this article has helped me a lot. It has cleared my questions on WSPBuilder, Using ASP.NET files, Deploying Sharepoint Project etc.
    Thanks a lot.
    Synfyn

  23. Harry
    August 13, 2009 at 8:14 pm

    This was a great post and really helped me out. Thank you so much.

  24. August 24, 2009 at 2:41 pm

    To those getting the “Could not load type ‘DemoProjectUI.DemoControl’.” error. The key line in the instructions above is: ‘Add an Assembly reference as the first line in this file’ And the key word in that line is ‘first’.

    I made the mistake of adding the reference after the reference and was getting those errors. Make sure that the reference is the first thing in your .ascx file.

    Thanks for the article Greg. Very helpful.

    • February 8, 2010 at 6:48 pm

      AGH!!!! Wasted an hour messing with this. Thanks for passing this little tip along!

  25. Stock
    August 27, 2009 at 12:50 am

    As far as I understand, your example is performed in the development box. Here is my questions: 1. Once the DemoProjectUI has been finished, how do you command the DemoProject to create wsp files and deploy them to the production box? 2. In our team, I develop the web part. Other people develope ASP.NET server controls. It means they have their own projects. Once they have finished their projects, they will give me all DLL files. In this scenario, what is the better way to architect different projects together? I am not clear about how the WSPBuilder project remotely receives DLL files from different ASP.NET projects which are made in different computers. Thanks.

    • Greg Galipeau
      August 27, 2009 at 12:30 pm

      My demo is performed on a develpment “server” (specifically a SharePoint server – specifically a SharePoint server virtual machine). If you are using WSPBuilder you can righ-click on the project and choose build wsp. Then you can take that wsp file and move it to whereever you want and use stsadm commands from SharePoint to deploy on other SharePoint servers. Stsadm has addsolution, deploysolution, retractsolution, deletesolution.

      As for your other developers creating things on other servers, that is not really the intent of this blog, nor how I usually setup my projects. You will have to work out a solution based on your situation. If your other developers are only building server side stuff (i.e.: server controls, classes, etc…), then you can just drop their dll into your GAC folder. If your other developers are building client/server side stuff (i.e.: user controls, etc…), then you will need to merge the files into the correct folders in your deployment project.

  26. Stock
    August 27, 2009 at 1:00 am

    Hi Greg,

    One more question: when you make the DemoProjectUI, you add the following into the post build section:
    xcopy “$(TargetPath)” “$(SolutionDir)DemoProject\GAC\” /Y /s
    xcopy “$(ProjectDir)*.ascx” “$(SolutionDir)DemoProject\12\TEMPLATE\CONTROLTEMPLATES\” /s /Y /R

    Are they real code? We should replace “TargetPath” or “ProjectDir” with our real directory?

    Stock

  27. Stock
    August 27, 2009 at 3:56 pm

    Hi Greg,

    Let’s say I am going to make DemoProjectUI as an ASP.NET project which has .aspx files and code behind files, but no user control ascx files. So, the UI is on the .aspx file. How does the WSPBuilder project DemoProject cooperate with DemoProjectUI?

    Stock

    • Greg Galipeau
      August 27, 2009 at 4:40 pm

      That answer varies depending on how you want to use the aspx pages in SharePoint (SharePoint works differently than most web sites). Where would you put the aspx files in SharePoint? Are they publishing pages or are they layout pages? So, the answer to this question varies a lot and is more subtable for a discussion on how SharePoint works with it’s pages (which is not the intent of this blog). However, I do use some of the techniques from this blog to deploy pages sometimes. But, it is more about knowing where to push them – into a feature, into the 12 hive for a layouts page, etc… Sorry I can’t give you an answer to this question in blog comments, it is more of a training thing on how SharePoint works with it’s pages and that discussion can get very long.

      • Stock
        August 27, 2009 at 6:47 pm

        My purpose is to convert the aspx pages and code behind files to a web part. It may be more complex compared to converting user control to the web part, which is your example here.

        In your DemoProjectUI, you add two lines into the post build section:
        xcopy “$(TargetPath)” “$(SolutionDir)DemoProject\GAC\” /Y /s
        xcopy “$(ProjectDir)*.ascx” “$(SolutionDir)DemoProject\12\TEMPLATE\CONTROLTEMPLATES\” /s /Y /R

        This is the solution for converting user controls to web part. However, how to convert aspx pages and code behind files to web part is not that simple. Do you experience it before?

        Stock

  28. Stock
    August 27, 2009 at 8:47 pm

    Hi Greg,

    I followed your example exactly. I made: 1) a WSPBuilder project named as WSP_For_Webpart. 2) a ASP.NET project ServerControls containing server control classes (a class library). The DLL file of this project goes to WSP_For_Webpart’s GAC folder. Inside the WSP_For_Webpart project, I made a web part feature called WPF (which is a web part). The scope for WPF is site. On the WPF.cs file, I reference the classes from the project ServerControls. Now, I build and deploy WSP_For_Webpart to my local SharePoint server. I have checked these things: The deployment is OK. All DLL files are stored in the box’s GAC. However, The directory Site Actions/Site Settings/Site Collection Features does not have the feature WPF. What is wrong here? Hope you have idea about that.

    Stock

    • Stock
      August 27, 2009 at 10:15 pm

      I solved the problems mentioned above. The problems were mainly that the webpart feature WPF was not installed and activated. I thought WSPBuilder should do all the jobs (including the ones above) when you choose “Deploy” function from WSPBuilder. But it seems that it leaves two jobs not completed and thereby I could not see my features installed and activated. If I understand correctly, it is a pity. Anyway, here is what I did to solve the problem. I made a cmd file with this script:

      @echo off
      set SPAdminTool=%CommonProgramFiles%\Microsoft Shared\web server extensions\12\BIN\stsadm.exe
      set PackageName=WSP_For_Webpart.wsp
      set FeatureName=WPF

      @REM — SET THIS VALUE PRIOR TO RUNNING SCRIPT —
      @REM THIS MUST BE SET TO A VALID SITE COLLECTION URL ON YOUR SYSTEM
      set DefaultSiteUrl=http://localhost

      echo Beginning %PackageName% Installation…
      echo Adding solution %PackageName% to the SharePoint …
      “%SPAdminTool%” -o addsolution -filename “%PackageName%”
      “%SPAdminTool%” -o execadmsvcjobs

      echo Deploying solution %PackageName% …
      “%SPAdminTool%” -o deploysolution -name “%PackageName%” -immediate -AllowGacDeployment -url “%DefaultSiteUrl%”
      “%SPAdminTool%” -o execadmsvcjobs

      echo Installing feature %FeatureName% …
      “%SPAdminTool%” -o installfeature -name %FeatureName% -force
      “%SPAdminTool%” -o execadmsvcjobs

      echo Activating feature %FeatureName% …
      “%SPAdminTool%” -o activatefeature -name %FeatureName% -url “%DefaultSiteUrl%” -force
      “%SPAdminTool%” -o execadmsvcjobs

      I ran this file. The problems solved. Now, I can see the feature WPF and it is activated. As a result, I can add the web part from WPF to the sharepoint page.

      Do you also need to run a script similar to the one I used in order to activate you feature? From your article here, you don’t do that. It is so strange I need to do it.

      Stock

      • Greg Galipeau
        August 27, 2009 at 11:04 pm

        Stock, you should read the steps more clearly. The steps clearly state that you should go to the site settings page, go to site collection features and activate the demo feature. Your script file is just a way of doing that through a script instead of manually doing it. In real production systems I do build a script file out, but for this blog I clearly stated you should activate the feature.

        • Stock
          August 28, 2009 at 3:02 pm

          Greg, I did follow your instruction to go to site collection features and tried to activate the new made feature. But it was not there. That is why I ran the cmd script. After running the script, it appears.

  29. Biju
    September 18, 2009 at 10:42 am

    Hi,
    I have developed an event handler,called TaskListEventHandler, for the Task list ((ItemAdding, ItemDeleting, ItemUpdating) as feasture using the WSP Builder project template, and I have also added a web part, called RegisterEventHandler, which will be used to bind(register) the events to a list. The webpart is WSP Builder template “Webpart without feature”.

    Currently, on deployment, my feature and the webpart is getting deployed sucessfully. The web part is also available in the web part gallery.

    Now i need to make the web part available in a particular category/group in the gallery using the WSP Builder?

    Whereas , when i try to deploy the.wsp using the stsadm manually the grouping is getting set sucessfully.

    I tried setting the group in the RegisterEventHandler.webpart file (which is automatically created by WSP builder on adding the webpart template inot the project), but still it doesn’t show up 😦

    Could anyone please help or suggest me some solution or sample code?

  30. Stock
    September 25, 2009 at 11:12 pm

    Hi Greg,

    In my user control, I have a web service file (.asmx). The user control will use the web method from there. What folder in DemoProject (the WSPBuilder project) should have this file? Thanks.

    Stock

  31. Jeff
    September 29, 2009 at 3:51 am

    Thanks for the article. I am trying to follow the instructions 100% and my plain web part looks like it is deployed as it is shown in the web part list, and in Central Administration as being deployed and inserted into the GAC.

    When I try to add it to a Web Parts page I get this error:

    DemoFeature: A Web Part or Web Form Control on this Page cannot be displayed or imported. The type cannot be found or it is not registered as safe.

    Any help would be great.

    Thanks,

    Jeff

    • Greg Galipeau
      September 29, 2009 at 12:41 pm

      For some reason it didn’t get marked as safe in the web.config file of your SharePiont site. If you deploy the WSP, from WSPBuilder, after the web application is created, then the WSP should take care of marking it as safe. So, I am not sure why it didn’t get marked as safe in your situation.

  32. sara
    September 30, 2009 at 11:16 am

    Nice Work !!!
    Try this too,
    Custom SharePoint WebParts

  33. Jeff
    September 30, 2009 at 10:29 pm

    Thanks for the Info!! this is my first time using Sharepoint and this is the best how to I have seen yet. However I have one problem if anyone has the time… I have created 5 DemoFeature projects now and with each one I can activate the feature and add it to the page. But I can never see the label text. any ideas?
    Thanks

  34. Goddard
    September 30, 2009 at 11:32 pm

    Now we need an article on writing a custom toolpart that contains a dynamic list of textboxes for storing webart settings. So for example:
    for each product in webpart.productarray
    Create textbox in toolpart to set the product’s detail form URL

    this would allow for setting list properties at sharepoint web page edit time.

  35. femi
    October 1, 2009 at 8:19 pm

    Hi,
    Great article!
    Is it possible to use LINQ to SQL in my Usercontrol and successfully get the webpart to work? Will i be able to create a LINQ Model in the Web Application?

    Thanks

    • Greg Galipeau
      October 1, 2009 at 9:37 pm

      Sure, LINQ to SQL is possible if you just want to connect to a database or something. I’ve done that before. You just need to make sure you servers are ready for it – upgraded to .net 3.5.

  36. Bill
    October 2, 2009 at 8:54 pm

    Hello,

    I just tried the above example and when I build the project the DemoControl.ascx does not move to the ControlTemplates folder in the DemoProject project. I then of course get an error that the file does not exist.

    Any ideas?
    Thanks

  37. Jeff
    October 6, 2009 at 3:36 pm

    Hello Again,
    I just wanted to check to make sure that no one can help me out with with this….
    I still can not see the label, I have run through this 5+ times and I can add the web part and so on, I can also debug and see that it does update the test.Text to “Hello WOrld” but I still can not see hello world within the web part.

    Thansk

    • Jeff
      October 6, 2009 at 3:58 pm

      ok… i will admit it… .I am a tard. All I had to do to get it to work was change the font color… it was working the whole time.. My bad. Great how to

  38. Greg Galipeau
    October 6, 2009 at 3:49 pm

    Hi Jeff,
    Unfortunately, it is very hard to help someone through comments of a blog. Sometimes it is possible with a very specific error, but it is very hard when it just doesn’t work. Have you tried the Demo Project link at the end of the article yet? It is a sample project with the walkthrough. Maybe you can see the differences of that verse the code you’ve been building.
    My other suggestion is don’t copy and paste from blogs. Sometimes I’ve seen quotes and other characters get messed up from the webpage to the code. I always suggest re-typing.
    Sorry I can’t be of more help,
    Greg

  39. October 7, 2009 at 12:57 am

    Hey Greg,

    I got some emails from this chain and figured I chime in.

    I finally got back around to this. You know I do not hate wspbuilder but I want to understand the interals a little lower. I was able to figure out how deploy the ASP.net web part from scratch. I used your stuff as guidance.

    http://www.k2distillery.com/2009/10/embed-and-deploy-user-control-in.html

    http://www.k2distillery.com/2009/09/user-control-error-in-sharepoint.html

  40. Annette
    November 6, 2009 at 9:47 am

    Hi Greg,

    Thank you for a great article!! It helped me a lot.

    Regards,
    Annette

  41. Payam
    December 27, 2009 at 9:05 am

    Thank you for a great blog and of showing a good way of creating web parts.
    Do you have any tips on how I easily can reuse this project for another project?
    To manually have to rename all folder and changing the build script seems like a lot of steps.

  42. Payam
    December 27, 2009 at 9:13 am

    Thank you for a great blog and of showing a good way of creating web parts.
    Do you have any tips on how I easily can reuse this project for another project?

  43. Payam
    December 27, 2009 at 9:17 am

    I am unsure if my last message was sent or not because of company site blocking. Anyway thank you for a great blog

  44. January 11, 2010 at 2:01 am

    Hi Greg,
    Thanks for the very detailed instructions in this great article.
    I am using VS2008 SP1 with WSPBuilder version 1.0.6
    After building and deploying the Web part to WSS 3.0 based Site, when I try to add the DemoFeature webpart I am getting the following error :
    “Unable to add selected Web part
    DemoFeature: A Web Part or Web Form Control on this Page cannot be displayed or imported. The type could not be found or it is not registered as safe.”

    Can you please help me to resolve it?

    Thanks.

    • Greg Galipeau
      January 11, 2010 at 2:40 am

      That error can be a couple things, but the first thing to check is whether your class got registered in the safe controls entry of your web.config. WSPBuilder should do this for you, but sometimes it gets messed up.
      Also, sometimes I like to completely uninstall the solution (there is a command in WSPBuilder for that) and then re-build and re-deploy. If the issue is happening because it is trying to update the solution (which happens sometimes), that will fix it. If that doesn’t help, then there is something else wrong with your solution that is keeping it from deploying correctly. Unfortunately, there are lots of things that can go wrong in SharePoint solutions and I would have to look at the code to know exactly what it is.

    • Michael R.
      February 24, 2010 at 9:54 pm

      I ran into the same issue as you Dominic. I was able to fix it by removing the root namespace from the project properties. I then rebuilt, built the wsp and deployed and everything worked fine. There are a couple of issues with doing this though. When you create any new web part features, you will need to modify both the .webpart file & the .vb file for the webpart to add the proper name space in both files.

      For example, if I have a Root name-space defined in the project properties, and I build and deploy my dll to the GAC, what happens if I use Reflector is that I see the name-space twice. For the project described above, it would have shown DemoProject.DemoProject as the name-space. Inside the webpart it would show DemoProject.DemoWebPart. That would cause it to fail when trying to add it to the page.

      If I don’t have the Root name-space defined in the project properties, then Reflector will show DemoProject as the name-space, and the web part should work properly in the page you add it to, however, as I said above, when adding new webparts, you will need to manually add the namespace to the .webpart file and the .vb file.

      BTW, I don’t know if it is just an issue with WSPBuilder and vb.net or if this also happens in a c# project.

      Anyway, hope this helps. Good Luck.

  45. Sam C.
    March 2, 2010 at 11:12 pm

    Hello Greg,
    Thanks for a great outline. I just had a question. When making a web application you have your own web.config file. I was wondering if anything you do in the web control web.config will not apply, to clarify, does it default to the SharePoint web.config.

    I am basically coming from my own web app that the client now wants to convert to a web part. So i thought i would convert the web app to a user control.

    Thanks

    • Greg Galipeau
      March 4, 2010 at 1:50 pm

      Yes, SharePoint uses the web.config file from the SharePoint Virtual Directory in IIS. This virtual directory is setup when you build your SharePoint site. The changes you make to the web.config file of your Visual Studio solution will not become part of SharePoint’s web.config. SharePoint does a lot of stuff to it’s own web.config file, so it doesn’t want you to overwrite that. But, there is something you can do programatically. SharePoint has an object in it’s api called spwebconfigmodification. It’s a little difficult to work with and isn’t perfect by any means. But, if you setup it up correctly you can make changes to “parts” of the SharePoint web.config through code. I would suggest looking into that object if you have lots of configuration changes you want to keep in sync. If you only have a few changes, just updating the SharePoint web.config manually always works (that’s usually my one exception to things I will do manually in SharePoint).

  46. Quang
    March 15, 2010 at 7:47 pm

    Michael R,
    so this appears to be only an issue with using WSPBuilder + vb.net webparts? Been using this walkthrough as a baseline but using vb.net instead of c# and have been running into the same issues. Is this a bug with WSPBuilder + vb.net webparts?

  47. Sam Rose
    March 25, 2010 at 3:55 pm

    Hello,
    Great solution thanks, Im trying though to use it with web part properties…

    [Personalizable(PersonalizationScope.Shared), WebBrowsable(true),
    WebDisplayName(“Help Wiki Name”),
    WebDescription(“The site of the help wiki”)]

    So I’m having to try to cast the control so that I can access the properies of the control…

    PZCSharePointWebParts.PZCTipOfTheDay myControl = (PZCSharePointWebParts.PZCTipOfTheDay)Page.LoadControl(“~/_controltemplates/PZCSharePointTipOfTheDay.ascx”);

    myControl.HelpWiki = HelpWiki;
    this.Controls.Add(myControl);

    But this results in..

    Unable to cast object of type ‘ASP._controltemplates_pzcsharepointtipoftheday_ascx’ to type ‘PZCSharePointWebParts.PZCTipOfTheDay’.

    Any ideas?

    • Greg Galipeau
      March 25, 2010 at 6:39 pm

      Hi Sam,
      Something I like to do is pass parameters into the constructor of the user control. To do that just create an overloaded constructor on your usercontrol with the variables you want to pass in. Then, create a “new” loadcontrol method on your webpart (I usually build a webpartbase class to put this method). This new loadcontrol method should be able to take in an array of parameters. Then, you can just pass in the parameters to your usercontrol constructor in the correct order. Here is a good post from Sahil Malik on how to do this: http://dotnetslackers.com/ASP_NET/re-23165_LoadControl_a_UserControl_and_pass_in_Constructor_Parameters.aspx

      Hope that helps,
      Greg

  48. sara
    September 30, 2009 at 11:17 am

    SharePoint WebParts, it is simple.
    Try this too,
    Custom SharePoint WebParts

  1. May 18, 2009 at 12:09 pm
  2. May 22, 2009 at 12:43 am
  3. December 3, 2009 at 4:19 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: