Tag: <span>SharePoint</span>

I’ve been using the SharePoint extensions for Visual Studio 2005/2008 for several months now, and after recently having a chance to see how some of the other tools work (WSPBuilder, STSDev, etc) I can safely say I like the extensions best. The other tools do some great things, but they both assume you’re using C#, and all my SharePoint stuff is done in VB.NET.

Version 1.2 for Visual Studio 2005 was OK, but wasn’t as easy to work with as the superior version 1.3 for Visual Studio 2008. I haven’t seen any of the betas for Visual Studio 2010, but I’m hoping the built-in SharePoint tools they’ve created will be even easier to use.

A while back I wrote an ASP.NET user control that FTPs files to a server. It has a FileUpload control that allows the user to select the file they want to transfer, plus it uses some AJAX stuff to display a running total of bytes that have been sent. And it works great. I can throw it on an aspx page and upload to my heart’s content. But if I load it inside a custom web part within SharePoint, it tragically fails 100% of the time.

My control uses a third-party FTP library that supports asynchronous uploads via a BeginUpload method. That’s what I’m using in order to periodically refresh part of the page with the byte count. But for reasons unknown, when this code executes inside the SharePoint environment, the file stream from the FileUpload control gets unexpectedly closed after 64 KB have been transferred. As expected, the FTP library reacts badly when this happens. The crazy part is I could get it to work in SharePoint if I removed any one piece of the equation: if I used the synchronous upload method of the FTP library instead of the async one, or if I opened another thread but did anything else in it except try to FTP a file (counting to 20 on the page worked fine). I originally had the FileUpload control inside an UpdatePanel, so I took it out. Same result. (I know that FileUpload isn’t strictly supported inside update panels, but I had the appropriate trigger set and it was working beforehand anyhow.)

My assumption is that SharePoint was disposing the FileUpload control even though it should have been available during the subsequent async postbacks. Maybe it’s all part of the incompatibility between FileUpload and AJAX. In any case, the solution was to simply save the file on the web server via Request.Files(0).SaveAs, then FTP it. I wasn’t happy about inducing an additional delay, but in testing it wasn’t terrible.  I also save the relevant properties of the FileUpload control, like the file path, content type and content length, before I start the FTP transfer so I don’t have to touch the control at all while the transfer is happening.

So far it’s working swimmingly, but SharePoint is not endearing itself to my heart.

My employer has two web sites: our main one that contains mostly marketing materials, and the support site, which customers must log into and which allows them to download our new software releases, get documentation, and do various other support-related activities. The main site is fairly current in terms of layout and organization, however, the support site is downright ancient. We’ve been planning on unveiling a new one for some time now. The current plan is to build it around Microsoft SharePoint.

I knew very little about SharePoint when I was tasked a week and a half ago to develop a web part that can be used to manage file downloads. I’ve been spending the time reading up on the technology and figuring out the best way of creating a custom web part that will do what we need it to do. So far the results have been both promising and a bit frustrating.

SharePoint itself is interesting, in a ‘wow, you sure can set up a lot of layout and content using just a browser’ kind of way. It also seems like there are 5 different ways to do everything, which is a common trait of Microsoft software. My biggest sore spot is how things are geared towards doing all the development work on the server. I initially though I could set up a server but then do all the coding on my regular XP machine. Sadly, that didn’t fly. I had to load Visual Studio on the virtual Windows 2003 machine I had set up. It all works fine, but it’s a hassle.

My download web part will be based on some existing ASP.NET code I wrote that never went into production. That code features a grid control that shows links with the exact layout and behavior I wanted. I was fearful that I’d have to somehow output all the HTML rendered by the grid, until I realized I can incorporate user controls into a web part. That discovery lead into a whole different set of options: build a web part that loads user controls, or use SmartPart, a web part written by Jan Tielens that makes hosting user controls quick and easy.

I’ve decided to go with the first approach, which is to skip SmartPart and basically mimic its behavior with my own web part. My reasons were twofold: I was persuaded by articles I read online about the pros and cons of SmartPart, and by the fact that it will give me a chance to really learn the mechanics of writing a custom web part, not to mention allow complete control over everything. At this point I’m trying to figure out the ideal way to pass data from SharePoint to my web part, and then from the web part to my existing user control. The struggle contrinues…