I am in the process of getting up to speed with the new Visual Studio 2010 IDE and how it can be used to develop custom SharePoint 2010 solutions.
It’s so easy to do a “Hello World” Web part project now. These days, my Hello World projects typically involve opening up a database table and displaying records in a table. I was able to do this with minimal coding and got it up and running—a full blown Web part—in under 15 minutes!
I created a sample project that opens up the AdventureWorks database and displays employee records in a table:
The Web-part looks like the following when used inside SharePoint:
- The Visual Web Part project cannot be deployed as a “sandboxed solution”. It has to be deployed as a farm solution.
- Project-debugging became a lot easier even with a full-blow farm-deployment. Press F5 in the VS 2010 IDE and Visual Studio will build, package, deploy, and activate your feature, and launch the debug-browser all in one click! When you’re done debugging, terminate Internet Explorer, Visual Studio will deactivate and retract the solution out of SharePoint.
- IIS-reset (for the target Web app) even for full-blown deployments when debugging is fast!
- Remember in VSeWSS 1.3 where you had to Google first how to specify the group the Web part appears in because it wasn’t so obvious? Well, it got easier in VS 2010! Now, the Elements.xml file has a place-holder for the Web-part group. All you have to do, is change it from “Custom” to whatever value you want it to be. It’s so visible now you can’t miss it.
- You can now add Web User Controls (ASCX files) into the project! As a matter of fact, the project template adds one ASCX file for you. This just made Web Part development a HECK of a lot easier! This is HUGE! Back in VS 2008 developing SharePoint 2007 Web parts, there were no designers available. If developers wanted to use ASCX files, they had to create regular ASP.NET Web apps, design the ASCX files there, write the code-behind, compile the project so the code-behind logic gets packaged with the ASCX files, deploy the ASCX files to UserControls folder within the SharePoint virtual Web app folder, deploy and enable Smart Part, add a Smart Part Web part to the SharePoint pages, then finally, hook-up the Smart Part to the ASCX files. Whew!!! Talk about LOTS of steps! In VS 2010, you don’t need Smart Part or that lengthy way to integrate ASCX file in SharePoint anymore. The challenge of “imagining” what your Web part will look like as you write your C# code is no more. The designer is built in to the Visual Web Part project. Leverage your ASP.NET skills to the max.
- Despite all the improvements, Web part development veterans should recognize familiar concepts and project files such as Elements.xml, .webpart file, strong-named key file, packages and features.
I have many ASP.NET developer friends who didn’t want to get into SharePoint development because:
- The Web part project wasn’t easy in SharePoint 2007. No designers, hard to design a visual element.
- ASP.NET developers got accustomed to easy debugging of their projects by simply pressing F5 key or the play button on the IDE toolbar. In 2007, ASP.NET developers thought deploying the app and then attaching to the w3wp.exe process (multiple manual steps, not one) was too cumbersome.
- It took forever to even debug the code because the SharePoint Web app always recycled on deployments.
If you are an ASP.NET developer contemplating if you should try SharePoint development, I highly recommend you try it NOW! SharePoint 2010 development feels like traditional ASP.NET development more than ever!
I am able to deploy and execute a ascx within a visual web part however I am able to reference a custom ascx within the parent ascx and have this all deploy properly.
http://social.msdn.microsoft.com/Forums/en/sharepoint2010programming/thread/4403a290-ee42-47b4-8a4d-65de9af60df9
Any thoughts or assistance would be greatly appreciated.
Hi John,
I read your post at social.msdn.microsoft.com. If I understand it correctly, you have 2 web parts, and each web part contained one ASCX file. You then tried to use the ASCX from one web part (DatePicker2UserControl) and embed it inside the other ASCX control (CustomerInfoUserControl). During runtime, the controls in the “child” (DatePicker2UserControl) were not initialized and were still null when attempted to be invoked via Page_Load of “parent” (CustomerInfoUserControl).
I attempted to replicate the error with one of my projects. At first I thought maybe the controls were not ready on Page_Init (where you were trying to add items to the DropDownList in DatePicker2UserControl). But I was able to add items to my DropDownList in my “child” control.
Next, I tried to get/set the property in the “child” control where the value is read/stored in the DropDownList itself. I tried to do this in the Page_Load of the “parent” (like you were doing in CustomerInfoUserControl). No errors for me there either.
Now, I’m curious why you say with regards to page-directives:
“In the previous ASP.net legacy application this was not necessary as the compiler could easily reference the user control. If I do not add this Register declaration, my application fails to compile as it can’t locate the Src attribute reference”
My reference for “child” control in my tests is of the form:
<%@ Register TagPrefix="uc1" TagName="ControlName" Src="~/_controltemplates/mypath/myControl.ascx" %>
It is odd that you would use the form where Namsepace and Assembly are specified instead of src, when all controls are really in the same assembly.
I would suggest you remove all references to DatePicker2UserControl in CustomerInforUserControl. Once it is clean, you can add back by dragging the DatePicker2UserControl.ascx into CustomerInforUserControl in Design mode. The reference should be added by then it should be of the form where src is included.
-Gabe
You are a King amoungst men!
It turned out that when I dragged the child ascx on to the form, it generated a src path that both compiled and runs perfectly within SharePoint.
I struggled to understand why this did not work for me previously as I read that it should on many posts. Your suggestion to pull it over in design mode generated the correct syntax to reference the child control(s).
Because you took the time to prove this works, it made me take a second look at my issue.
Thank you so very much for taking the time to review and assist me, I am ever so grateful.
You’re welcome John. It didn’t take me that long to replicate your issue. Like I said, easier to develop Web parts in VS 2010/SP 2010 Visual Web parts.
I’m glad you’re also able to resolve how to package your images!
-Gabe
Sorry, but I am new to SP 2010 developement and need to understand how I package up my image folder within my feature within SharePoint 2010?
Is that done as a module?
Sorry, I found that this was accomplished through a Mapped Image folder.
Hi Gabe
I am hoping that you will be able to confirm my approach below prior to me starting as it will be quite a lot of work but I am determined and will follow this approach if it is the correct approach.
I am trying to migrate the functionality of a legacy ASP.Net application. Earlier you helped me with a particular aspect of this migration which was to wrap the ascx user controls in Visual Web parts. I am now trying to complete the migration and would love if you could provide some guidance on my approach.
The legacy ASP.Net application consists of a series of ASP.Net pages which inherit from an Asp.net Master Page.
In the Master Page there exists two ContentPlaceHolders (cph_left, cph_center)
The first ContentPlaceHolder (cph_left) has its content filled with specific user controls that will always be there no matter what page the user is on, while the other ContentPlaceHolder (cph_center) is empty in the master page and is populated by each of the aspx pages such that the cph_center contains different content (divs, user controls etc. ) depending on the page the user was on.
In the legacy aspx page(s), the code behind has access to each instance of each ascx it has placed within the cph_center and thus is able to control them as needed. For example, depending on what options are enable, the code behind might hide or show a user control within a particular legacy aspx page.
As you may have gathered, I am attempting to port this application over to SharePoint and I am hoping you are able to confirm my approach.
Here is what I beleive I need to do but please tell me if I am wrong;
Step 1:
Create a page layout which inherits from my custom master page(s) and then add my ContentPlaceHolders (cph_left, cph_center) and any additional Web part Zones to support the dropping of Visual Web Parts.
In my custom layout page I would add the same visual web parts directly to page to ensure that the same user controls are always showing on the left side as was in the legacy application. This might also be accomplished through the use of a web part zone and customize this zone within each page.
I am fairly confident with how to do this and feel I will be able to create a page layout within Visual Studio to suit my needs. I have created some very nice master pages thus I have no issues with this step.
Step 2: (This is the step you helped me with which is complete)
Create visual web parts based upon the ascx user controls. This worked perfectly thanks to you. As a result I am now easily able to add these web parts to SharePoint and they access the legacy data and render as they do in the legacy application work as they did before. The area I struggled with was when a user control was a composite of other user controls. Your assistance helped me through this as such I have no issues with Step 2.
Step 3: (This is where I am unsure if my approach is the right approach)
In order to control the center content similar to the behavior of the legacy aspx page I think I need to create a new User Control which would encapsulate the exact same content as the legacy aspx page which includes any user controls that were part of that content within the legacy aspx page along with the existing logic that was part of the legacy aspx page’s code behind.
Once I have this new user control, I than turn that into a Visual Web part which would be used in step 5 below. Is this the correct approach or is there an easier way?
Step 4:
Place the visual web parts from step 2 on to my page layout within the cph_left ContentPlaceHolder.
Step 5:
Create site pages based upon the Layout pages created in Step 1 and 4 and place my Visual web parts as created in Step 3 into the cph_center ContentPlaceHolder.
Con you please confirm if this is the correct approach or not.
I just tried this on one page and it appears to work, I now see legacy aspx page contents inside my a new visual web part.
I am not certain is this is the desired approach. Any assistance would be greatly appreciated.
Hi John,
Porting a full-blown ASP.NET application to run in SharePoint, if I read you right, you’re creating Web parts that contain the Web controls. You’ll have multiple Web parts deployed with this approach. If the SharePoint site-collection that the app will be running on also have sub-sites, these Web parts may not stand on their own feet (they came from a .NET app, some of these “Web parts” will probably need data to be passed to it via forms-data or querystring). My point is your SharePoint Web Part Gallery will be littered with Web parts that probably cannot be used outside of your “application”. I don’t do these for “traditional apps” that I want to run in SharePoint.
I would recommend the following approaches instead:
a) Re-engineer the ASP.NET app to have Web services. You can then consume those Web services in the SharePoint pages (inline scripting)
b) Create a custom SharePoint Solution project. Just like in the ASP.NET project, you will have master-pages, Web controls, resource files such as images and JavaScripts. You package the solution as a SharePoint feature and you deploy to SharePoint. Activate the feature in SharePoint and those Web controls and pages should be available.
-Gabe
Thanks Gabe & John
You just saved me! I was getting the same odd null child control behaviour due to a messed up Register tag.
-Gavin
You’re welcome Gavin!
.-” I am really thankful to this topic because it really gives up to date information “”
My problem is, I have created 5 visual web parts in one solution on test environment and they are working fine on Test server. I want to deploy these visual webparts onto Production server.
Direct deploy fails with some user permission, I could not find anything to deploy this webpart on prod server. Which files (ascx, image, javascript, dll, wsp) to deploy on server and steps need to be followed.