Jake Opines : ASP.NET

SharePoint Saturday: Developing and Packaging a Third Party SharePoint Solution

jacobl — Mon, 12 Jan 2009 15:34:44 GMT

Here are some notes from my presentation at SharePoint Saturday this past weekend in Virginia Beach, VA. Included are my slides, code that I demo'd, and hopefully answers to all of the questions that people asked.

The Slides

Download my slides in PDF form for quick reference.

Download my slides as a QuickTime movie to view the presentation with all animations. Unfortunately, to keep the file size low, I had to sacrifice a lot of quality. I suggest you download both the PDF and movie to get the full effect.

The Code

The Feature that we worked on uses a toolkit called DotImage. If you're interested in using the feature for testing, feel free to get an evaluation license.

Download the source code.

Download the WSP file (you will need to get an evaluation license for DotImage)

SPWebConfigModification

Here are links to Dave Terrell's 6 part series on using the SPWebConfigModification object to edit the web config of a given Web Application in SharePoint.

WSPBuilder

Check out my short blog post on WSPBuilder with instructions on how to use it in a NAnt build script.

SharePoint Solution Installer

I will post a more extensive article with instructions on how to use this product and some ideas on how it might be improved, but for now, you can find the SharePoint Solution installer on CodePlex.

AllowUnsafeUpdates

Check out Hristo Pavlov's blog on AllowUnsafeUpdates here.

My Presentation Setup

Here's a little more detail on the setup I used in my presentation: the computers I was using, which ones were VMs, how I switched between them and my slides, what presentation software I used, and how I tied it all together.

SharePoint Box

Since SharePoint is a bit of a beast, I decided to run it on an external machine. It was running on a Sony Viao with Vista. WSS 3.0 was installed directly on Vista. I will post on that in a week or so explaining how that's possible with steps on getting it done yourself.

Visual Studio Machine

I prefer to run Visual Studio on a different machine that I run SharePoint. The primary reason for this is so that I can quickly revert the VM that's running SharePoint in my development cycle without worrying about losing work.

For my presentation, I ran Visual Studio on a virtual machine in VMWare Fusion for Mac running Windows XP Pro.

Tying them Together

Since there was no guarantee of wireless offered at the Advanced Technology Center, I made sure I was all set by hosting a wireless network from my Mac and connecting to it from the Vista laptop. From there, I was able to remote in and get to SharePoint.

Presentation Software

I enjoy using Apple's Keynote software. It lets me make very attractive slides and is very easy to use. Plus, it exports to many formats that anyone can read without losing anything like transitions or animations.

Switching between Everything

To switch between my slides and my 2 demo machines, I used a built-in Mac feature called Spaces. It's a beautiful implementation of multiple-desktops.

KeepAlive for the DotImage WebThumbnailViewer

jacobl — Fri, 09 Jan 2009 13:20:27 GMT

This is my third post on the topic of using a simple JavaScript call to keep a server session alive. My first post was on keeping a generic IIS session alive by reloading a hidden GIF, my second was related directly to keeping session state alive for the WebImageViewer, and this post will address the WebThumbnailViewer.

Using the WebThumbnailViewer with the WebImageViewer

If you're interested in keeping a session alive for a page that contains both a WebImageViewer and a WebThumbnailViewer working in tandem, you only need to keep the session for the WebImageViewer alive since they share the same stamp file in the AtalaCache. However, if you are using just the WebThumbnailViewer, this blog is for you.

Server Side

Luckily, you need not make any change to your code-behind. There is something very simple that we can call in DotImage on the client-side that will do the job for us.

Client Side

This is super simple. WebThumbnailViewer has an UpdateThumb call that does a round trip to the server, requests a thumb, and serves it. This causes the state keepalive that we are looking for.

        1: var keepAliveIframe = null;

       2: function KeepAlive(){

       3:     WebThumbnailViewer1.UpdateThumb(0);

       4: }

       5: setInterval('KeepAlive();', '900000');

That's it. Just add that function to your page and you'll be all set. Don't forget to update the setInterval duration to something that makes sense for your deployments. 900,000 milliseconds is 15 minutes so that should work in most cases.

KeepAlive for the DotImage WebImageViewer

jacobl — Wed, 31 Dec 2008 13:22:17 GMT

Recently, I posted an article describing a simple way to keep a session alive during long periods of inactivity. That works great if your web application doesn't rely on some other information on the server to maintain state. If you use DotImage in your web app, it maintains certain state information in the AtalaCache that needs to be updated every so often. If not, you run the risk of another user hitting the page and causing the AtalaCache to be cleaned up (assuming the cache has expired). This post explains how to avoid this by forcing the WebImageViewer to update its timestamps on your state.

Server Side

In your page's code behind, add the following RemoteInvokable function:

        1: [RemoteInvokable]

       2: public void Remote_KeepSessionAlive()

       3: {

       4:     // Don't need to do anything here.

       5:     // A simple page request will force the

       6:     // WebImageViewer to update any timestamps 

       7:     // it needs for this session.

       8: }

Client Side

In your aspx page, add the following JavaScript:

       1: function KeepAlive(){

       2:     WebImageViewer1.RemoteInvoke('Remote_KeepSessionAlive');

       3: }

       4: setInterval('KeepAlive();', '900000');

We don't need to pass anything into the RemoteInvoke and we don't need to set an event handler for the return since it doesn't matter to us. Very simple.

This RemoteInvoke-based keepalive for the DotImage WebImageViewer will fire every 15 minutes (or 900,000 milliseconds == half of my session lifetime). Make sure you adjust that duration according to your server's session. Be sure to set it to something less than your session timeout or you might miss it.

A Note Regarding YUI and the WebImageViewer

jacobl — Mon, 21 Jul 2008 12:50:00 GMT

When developing two of my applications for 31 Apps in 31 Days (here and here), I discovered an issue with using YUI with our WebImageViewer. The script tag that references the YUI js files must be inside the main form element. If it is not, the DOM of the WebImageViewer gets distroyed and multiple painful errors ensue.

<..WebImageViewer .. />

// Your JavaScript Goes Here ...

</script>

</form>

...

</body>
</html>

This may also be the case with other third party javascript libraries. I have experienced receiving a similar error when using ExtJS, but didn't try this fix at the time.

Queuing up Your Remote Invokes

jacobl — Tue, 24 Jun 2008 17:40:00 GMT

The WebImageViewer is a very powerful web control that we offer to our customers. It does a lot of work for you behind the scenes to make the experience as application-like as possible. It even takes that a step further with the RemoteInvoke method and RemoteInvoked event by providing customers with the ability to make server-side function calls in an AJAXy way while not requiring that they know anything about how it works behind the scenes.

Wait Your Turn!

RemoteInvoking with the WebImageViewer makes an assumption that much of AJAX-based web techniques make: you must serialize your requests or they will step on each other. (Serialize in the sense that they are not parallel... not turn into a bytified version of an object). This can be a little annoying if you don't know what you are doing or if your user works faster than you expected. You must make the appropriate accommodations such as locking up the UI while background processing is happening.

The Other Approach

Locking up the UI might not seem like the best option. You might want to allow your users to send multiple requests to the server and just have them be processed at will. This is where this little piece of code comes in. It wraps the WebImageViewer's RemoteInvoke system in a queuing service. You simply create a new Remoter JavaScript object by passing in the WebImageViewer object and you're off to the races. You'll have to make a few minor modifications to your RemoteInvoke calls and RemoteInvoked event handler assignments, but it's all well worth it.

Here's what it looks like to make a RemoteInvoke call with the WebImageViewer:

WebImageViewer1.RemoteInvoked = OnRemoteInvoked;
WebImageViewer1.RemoteInvoke("RemoteMethod", new Array("array", "of", "args"));

function OnRemoteInvoked()
{
WebImageViewer1.RemoteInvoked = function() {};
// any post-request processing goes here
}

Here's what it looks like when using the Remoter class:

var remoter = new Remoter("WebImageViewer1");
remoter.RemoteInvoke("RemoteMethod", new Array("array", "of", "args"), OnRemoteInvoked);

function OnRemoteInvoked()
{
// any post-request processing goes here
}

What's for free?

You get something out of this for free that you might not expect. In addition to having all of your remote requests queued up so that they automatically don't stomp on each other, you also get the benefit of not having to reset your RemoteInvoked event handler. You're forced to set the RemoteInvoked function each time, and it is always set to an empty function if you don't.

With this handy little utility, you can do stuff like this:

var remoter = new Remoter(WebImageViewer1);

remoter.RemoteInvoke("RemoteMethod1", new Array(), OnRemoteInvoked1);

remoter.RemoteInvoke("RemoteMethod2", new Array(), OnRemoteInvoked2);

remoter.RemoteInvoke("RemoteMethod3", new Array(), OnRemoteInvoked3);

As each request is sent to the server and a response is received back, the next request will fire.

client ----> RemoteMethod1 -----> server
client <---- OnRemoteInvoked1 <----server

client ----> RemoteMethod2 -----> server
client <---- OnRemoteInvoked2 <----server

client ----> RemoteMethod3 -----> server
client <---- OnRemoteInvoked3 <----server

How do I use it?

After you download it using the link below, include it in your project. Add the following script tag to include it in your aspx page.

That line must go in the same <form> that your WebImageViewer or WebAnnotationViewer is in. Next, you need to add the following line to the function that is called once the WebImageViewer is done loading.

var remoter = new Remoter(WebImageViewer1);

Replace WebImageViewer1 with the id of your WebImageViewer or WebAnnotationViewer. To make sure that this function is called at the right moment, call it with atalaInitClientScript(); like so:

atalaInitClientScript("OnPageLoad();");

function OnPageLoad()
{

var remoter =new Remoter(WebImageViewer1);
// other code that you want to call after the WebImageViewer is initialized.

}

</script>

Where do I get it?

Remoter is not part of DotImage, but can be downloaded here and used for free.

If you happen to be a PHP developer, check out my personal blog for information about Remoter's adaptation to PHP.

Full-Screening your WebImageViewer

jacobl — Tue, 27 May 2008 17:20:00 GMT

Last week, I posted 2 web apps (here and here) as part of our 31 Apps in 31 Days promotion. They both have one thing in common (outside of the fact that they're online): being full screen WebImageViewers. There are a few hoops that you need to hop through to make it happen, and this article will walk you through it.

1. Create a new Web Site project with nothing on the Default.aspx page except for the Atalasoft WebImageViewer.

2. Set the Width and Height properties in the image viewer to 100%.

3. Height is a funny beast. It needs to be set in every tag going up the tree to (AND INCLUDING) <html>. To set the height of each of these properties, add the following attribute to each of those elements up the tree:

style="height:100%; width:100%"

4. In your body tag, we need to make all the browsers not show the main windows scroll bars so that we only see the scroll bars of the WebImageViewer. To do that, add this attribute to the <body> tag:

style="overflow:hidden;"

This basically means that if the browser detects any content that stretches beyond the height of the page, it will just not show it. In our case, this is perfect because anything the browser thinks is there is probably just an off-by-one-pixel issue...

5. Lastly, we need to fix a little issue with IE. Internet Explorer doesn't get rid of the vertical scroll-bar after simply adding the style in step 4. It just grays it out. That's not good enough. Add this last attribute to the <body> tag:

scroll="no"

Visual Studio will say it's not a valid property (the same would have happened when you added the style to your <html> tag, but that's ok.

That's it! Now, the tricky part is figuring out how to build your interface on top of the image viewer instead of around it. In ThinDoc, the elements are absolutely positioned to the right (for the controls) and on the bottom-center (for the thumbnails). They appear whenever the mouse moves, but won't go away when the user is hovering over either of those controls.

For a sample of this in action, go to my post about ThinDoc and download the source.

"Bad, IIS. Bad!" - Forcing IIS to run your site in .NET 2.0

jacobl — Thu, 03 Apr 2008 14:43:00 GMT

I was working in IIS, today, and came across an issue where it was attempting to load my site in ASP.NET 1.1.xxx. I, for one, know that the site I was deploying was built as a precompiled web from VS2005, which, as far as I know, means that it's .NET 2.0 for sure. I also knew that all of the assemblies I was referencing were .NET 2.0 and the web config had all the appropriate .NET 2.0 love.

The first thing I did was search around IIS to see if there was a way to beat it into submission and force it to run the site in ASP.NET 2.0. No luck... I believe the newer versions of IIS have this functionality, because I swear I've used it before, but I wanted to deploy now!

After a bit of searching, I came across this great little utility called ASP.NET Version Switcher that saved me a boatload of time by Denis Bauer. It shows all of the sites in IIS and easily lets you switch the .NET Framework version for any one. Granted, it just runs the command line utility that I'm sure is easy enough to figure out, but GUIs are nice too.