Adding a gallery to your .NET 4.0 application

After a frustrated user posted his troubles getting GSP to work in a .NET 4.0 application, I thought I would dig into it to see what was going on. I have step by step directions for Visual Studio 2008 in the Admin Guide, but it turns out they don’t quite work for Visual Studio 2010. I also felt I could improve upon the explanation that is in the Admin Guide, so I decided to completely rewrite it in this blog post. Eventually I will update the Admin Guide to include this information.

I will create a default .NET 4.0 web application and then add a gallery to it. These steps are largely the same for Visual Studio 2005 and 2008, too.

Download the sample application I created for this post. A couple notes: (1) Log in to the gallery with username Admin (password=111). (2) For demonstration purposes, it includes the latest release of the AJAX Control Toolkit, not the version that ships with GSP.

Integration strategies

First, let’s review the ways one can add a gallery into an existing ASP.NET app, in order from least coupled to most coupled:

1. Deploy the GSP support files and DLLs and don’t use assembly references – The contents of the gs directory are deployed to your server but not included as content files in your Visual Studio project. The GSP assemblies are deployed to the bin directory but not referenced by the project. The only parts of your project that are “aware” of GSP are: (1) App_GlobalResources contains the resource file GalleryServerPro.resx, (2) web.config contains the required GSP configuration, (3) the web page for the gallery contains a Register tag for the GSP user control and, of course, the Gallery user control itself.

The advantage of this approach are:

1. You can add a gallery to your site without having to recompile it.
2. You can update to new versions of GSP without having to recompile – just copy the new files to your server.
3. Your Visual Studio project has minimal knowledge of GSP, which helps to keep things clean and allows you to focus on your application without thinking too much about GSP.

The disadvantages of this approach are:

1. You cannot use the GSP API (which may be used in advanced customization scenarios).
2. You no longer have your entire app contained within a single project, which makes management more difficult.
3. You cannot use the built-in publishing functionality in Visual Studio to deploy your app. Well, not the GSP portion anyway.

This is the approach I use for the demo gallery on www.galleryserverpro.com.

2. Include the files as part of the Visual Studio solution, but don’t reference the GSP DLLs – Copy the gs directory and other files into your app and make them part of your solution/project. This is the method documented in the Admin Guide. It has the advantage of keeping everything organized in one project, which allows for simple source control and deployment, but tends to clutter up your app with GSP dependencies that can be a distraction.

3. Same as above, but also reference the GSP DLLs - Copy the files into your app and make them part of your solution/project. Add references to the GSP assemblies to make your app aware of GSP. This is required when you use the API in advanced scenarios (for example, if you want to create your own upload page and add media objects yourself). But doing this in .NET versions higher than 2.0 will often give you compile errors. They are all solvable without too much work, but they can be a hassle.

Step by step: Adding a gallery

Each strategy can be the right solution depending on your requirements. Unless you intend to use the GSP API, most developers will want to use the first or second technique.

Here are step by step directions for adding a gallery to an existing .NET 4.0 application using the first strategy. In this example, I’ll use Visual Studio 2010 Ultimate to add a gallery to a default ASP.NET application. Just for fun, I am using a Visual Basic project, which works great even though GSP is written in C#. I believe the steps are the same for all web-enabled versions of Visual Studio, including the free Express one.

Note: By default, Visual Studio creates pages that require compilation, but at the end of this post I’ll show how to create pages that don’t require compilation, thus providing you with the no-compile advantage I mentioned above.

Note: If you already have an existing web app, skip to step # 3.

1. Use Visual Studio 2010 to create a new ASP.NET 4.0 application using the ASP.NET Web Application template. Here I am using Visual Basic, but you can use another language.

   

2. The project will be created. In Solution Explorer, right click Default.aspx and choose View in Browser. The home page appears:

   

3. Okay! We have a working ASP.NET 4.0 app. Now we want to add a gallery to it. If you do not have an App_GlobalResources directory in your application, create one by using Visual Studio to right click the web project node in the Solution Explorer and choosing Add - Add ASP.NET Folder - App_GlobalResources. Similarly, add an App_Data folder if your project does not have one.

4. Download the compiled version of Gallery Server Pro and extract the contents to a temporary directory. Use Windows Explorer to copy the following items:

   1. Copy the gs directory into your ASP.NET app. It should be at the same level as your other top-level directories, such as App_Data.
   2. Copy the contents of the bin directory into your bin directory.
   3. Copy GalleryServerPro.resx from App_GlobalResources into the same directory in your app.
   4. Copy galleryserverpro_data.sqlite from App_Data into the same directory in your app (not necessary if you use SQL Server).
   5. Copy web_4.0.config into the root of your app. Delete the existing web.config and rename web_4.0.config to web.config. NOTE: Your web.config may have settings you need to preserve, so you may need to manually merge the two instead.

5. Create a new web page to hold the gallery. In this example, I created a page named Gallery.aspx from the Web Form Using Master Page template and then selected Site.Master for the master page. At the top of the page add a line to tell the page where the Gallery user control is defined:

   <%@ Register TagPrefix="gsp" Namespace="GalleryServerPro.Web" Assembly="GalleryServerPro.Web" %>

6. Then add the user control somewhere in the body of the page:

   <gsp:Gallery ID="g" runat="server" />

7. Compile the application. You will probably get the compilation error “Type ‘GalleryServerPro.Web.Gallery’ is not defined”, as seen here:

   

8. This error is not covered in the Admin Guide because it never happened under Visual Studio 2008. The reason for this error is because Visual Studio added a definition for the control in the page’s designer file and the compiler doesn’t know where the user control is defined. This doesn’t seem right to me - I would argue that it should know where it is because we explicitly defined it in the <%@ Register … /> tag.

9. But no matter, because we can easily fix it. Double click the error to show the offending code:

   

10. Delete the line that is causing the error. As best I can tell there are no harmful consequences to removing it. The page will look like this when you are done:

    

11. Now compile the application. It should succeed. Right click the page and choose View in Browser. The page will appear with an empty gallery:

    

12. By default, no users are defined and the gallery is configured to use SQLite for data storage, so run the install wizard to set up the membership system and optionally configure SQL Server. In the web browser, add “?g=install” to the URL. The install wizard appears:

    

13. Step through the install wizard. When complete, you are redirected back to your gallery, which now includes a sample album and image. All done!

    

Integrating with existing users

The integration example above assumes you are setting up a new set of users, but you might want the gallery to be integrated with your existing membership provider. After running the install wizard, open web.config and update the membership, role, and profile sections to point to the desired providers. GSP will use the default provider unless you specify a particular provider in the galleryserverpro.config settings membershipProviderName and roleProviderName.

After pointing web.config to your membership, you may get the following error:

This is happening because GSP doesn’t know what kind of security access any of your users have, so it assumes a “better safe than sorry” position and doesn’t let anybody in. To define the administrator, open the table gs_Role. GSP should have created a list of records in this table that mirror the roles in your role provider (if you don’t see any, try restarting the web app, which triggers the validation code that synchronizes the roles in gs_Role with the roles in your role provider). Pick the record that represents the system administrator role and set the AllowAdministerSite column to true. Then restart the app (or edit the album summary, which clears the role cache). Any users in this role should now have full administrative permission to the gallery. Now that you can log on as an administrator, you can use the normal GSP admin functions to define the security for the rest of the users.

No compile option

To add a gallery to your app without requiring compilation, remove the code behind file from the web page that contains the gallery user control. For example, in the example above, change the first line from this:

<%@ Page Title="" Language="vb" AutoEventWireup="false" MasterPageFile="~/Site.Master" CodeBehind="Gallery.aspx.vb" Inherits="WebWithGsp.Gallery" %>

to this:

<%@ Page Title="" Language="vb" AutoEventWireup="false" MasterPageFile="~/Site.Master" %>

After this change, the code behind files Gallery.aspx.vb and Gallery.aspx.designer.vb are no longer need and can be deleted.

An added benefit to this option is that you won’t be affected by the compile error we received above, since the designer file does not exist.

ASP.NET compatibility

Update 2010-08-03: Check out this blog post for more info.

If you look carefully at the screen shots, you will notice we lost the nice formatting of the menu after we added the gallery:

This is because the 4.0 version of web.config that ships with GSP is configured to render objects the pre-4.0 way. That is, the attribute controlRenderingCompatibilityVersion is set to 3.5:

<pages theme="" styleSheetTheme="" validateRequest="false" controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID" />

This is an application wide setting, so this causes the menu to render using tables (<table>) rather than list items (<li>), which breaks the CSS in the default ASP.NET application.

You can restore the formatting of the menu by setting the compatibility version to 4.0, or removing it altogether. After this change, it looks like this:

I specified 3.5 compatibility mode in web.config because I wanted to guarantee that everything worked the same in .NET 4.0. I am not sure it is required, though. In some very brief testing, I couldn’t find anything that was broken in 4.0 mode. It is possible that future releases will default to the native 4.0 rendering.

AJAX Control Toolkit

GSP ships with version 1.0.10920 of the AJAX Control Toolkit, which is the most recent version of the toolkit that is compatible with .NET 2.0. If you want to use later versions in your app, GSP will work with it, but you must update web.config so that GSP uses the desired version rather than looking in vain for the one it was compiled against. Open web.config and add this line just before the final </configuration> element:

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity name="AjaxControlToolkit" publicKeyToken="28f01b0e84b6d53e" />
      <bindingRedirect oldVersion="1.0.0.0-1.1.0.0" newVersion="4.1.40412.0" />
     </dependentAssembly>
  </assemblyBinding>
</runtime>

Update the newVersion attribute as needed to reflect the version of your AjaxControlToolkit.dll.

MVC apps

GSP is a webforms application, which is very different than the MVC pattern recently introduced by Microsoft. Generally speaking, webforms and MVC functionality don’t belong in the same application and can give you trouble if you try.

Having said that, it *is* possible to add a gallery to an MVC app. I actually did it for a customer not long ago. Here are the key lessons I learned:

• The gallery user control must be added to a webforms page, not an MVC one.

• I added a line to global.asax to tell the routing system to ignore paths to the webforms page. In my case, I put the webform (an .aspx page containing the Gallery user control) in a directory named Webforms and then added this line to global.asax: routes.IgnoreRoute("Webforms/{*pathInfo}");

• The javascript on the Rearrange objects page failed until I set controlRenderingCompatibilityVersion to “3.5” in web.config.

• Getting MVC and webform pages to share the same master page is difficult. I actually had to define a top level master page Root.Master that inherited from System.Web.UI.MasterPage. In this page I put the main layout. Then I created two child master pages – one was called Mvc.Master and it inherited System.Web.Mvc.ViewMasterPage; the other was called Webform.Master and it inherited from System.Web.UI.MasterPage. Both child pages used Root.Master as its own master page, and served as essentially empty containers for the web pages. All MVC pages used Mvc.Master; webforms used Webform.Master. A big problem with this approach is that the top level master page cannot use any MVC code. And if you add something to Mvc.Master, you must duplicate it in Webform.Master. This is a fragile approach that might create maintainability issues down the road, but I couldn’t come up with anything better. An alternative was to create identical master pages – one for MVC and one for webforms, but that is obviously not ideal.

Turning a lemon into lemonade: Multiple galleries in a single web application

A clash between DotNetNuke portals and Gallery Server Pro architecture

Back in March I released an alpha build to a few select users for a new DotNetNuke module version of Gallery Server Pro. At the time I thought I was nearly done. Well, it turns out that DotNetNuke has one feature that conflicted with GSP’s architecture: Multiple Portals. And I’ve been working to resolve this ever since.

Portals are a concept in DNN where a single web application can have one or more mini-web sites that appear – to the outside world – as if they are separate applications. They can even have different URLs: www.p1.site.com, www.p2.site.com, etc. For example, a user navigating to www.p1.site.com would see a site that looks completely different than www.p2.site.com. It can have a different theme, different content, and even different users, but behind the scenes it is a single web application connecting to a single database.

My alpha testers noticed that the GSP module worked fine EXCEPT that media objects were shared across multiple portals. Not cool - Each portal must have its own set of media objects and its own administration settings. At first I thought – no big deal – GSP already has the concept of a gallery – all I need to do is create a unique gallery for each portal.

The problem, however, was that the Gallery ID was specified in galleryserverpro.config, and there is only one of those per web application. I had to figure out how to manage multiple galleries within *one* application. There was no way to shoehorn the config file to support multiple galleries unless I radically changed its structure. Even then, an administrator updating a setting in one portal would cause the entire application pool to recycle, since that is how the ASP.NET configuration system works. Something big had to change.

Refactoring gallery settings to the database

In the end, I abandoned the galleryserverpro.config file and moved everything into the database. There are now five new tables:

gs_GallerySetting – Stores most of the items in the <core> section of galleryserverpro.config, such as ShowErrorDetails and MediaObjectPath. The column FKGalleryId is a foreign key to gs_Gallery, so each gallery gets its own set of settings.

gs_AppSetting – It made sense to keep a few items from galleryserverpro.config at the application level, and these are stored here. It has just a few records that apply to all galleries, such as JQueryScriptPath and ProductKey.

gs_BrowserTemplate – These are the HTML templates from galleryserverpro.config.

gs_MimeType – This is a read-only list of all MIME types.

gs_MimeTypeGallery – This stores whether each MIME type is enabled or disabled for a gallery.

These changes were applied to the source code trunk, meaning it affects the main release of GSP in addition to the DotNetNuke branch.

With these changes, the next version of GSP will support multiple, distinct sets of media objects within a single web application. Each set – called a gallery – has its own settings, users and roles. From the user’s perspective, the media objects are completely isolated from each other, although a site administrator can move or copy objects between galleries. And the galleryserverpro.config file has been confined to the dustbins of history.

A quick note about users and roles: GSP continues to use the membership and role provider model. This model enforces a unique set of user and role names across the entire application. That means that once a user is created, that username cannot be created again in other galleries. You can, however, *share* users and roles across galleries. For example, you can assign user ‘Bob’ to have view permission in gallery 1, write permission in gallery 2, and no permission whatsoever in gallery 3.

I used the phrase “turning lemon into lemonade” in the title because this was not something I wanted to spend three months working on, nor do I think this is a feature that regular GSP users are clamoring for. I would have rather spent this time adding tagging support, improving the upload experience, or just about any of the one hundred items on my to-do list.

Making lemonade

However, it turns out there are significant benefits to this change. One of my favorites is that the application pool no longer recycles when you update a setting. Now you can edit a setting without affecting any in-progress uploads or synchronizations.

Plus, more complex scenarios suddenly become possible:

• You want to have one gallery for staging and another for production. Media objects are first added to the staging area, where they are organized and prepped. When they are ready to be deployed, they can be moved or copied to the production gallery.
• You have departments in your company that should each have their own gallery. Each gallery should have its own administrator and can have its own settings, such as user accounts, watermark, permissions, etc. Rather than setting up and maintaining multiple web applications, this can now be handled in a single app.
• You have media files in multiple locations you want to expose, such as D:\Pictures and D:\Video.
• You want to set up a gallery for each member of your family. Each person is a mini-administrator for their area and can't edit another person's media objects, yet everything is contained within a single web application and database.
• You want some images to be 640x480 and others to be smaller (or larger).
• You want to have a watermark applied to one set of images but another set should have no watermark, and all images are to be accessible to anonymous users. Or you have different watermarks that should be applied to different sets of images.
• You want to provide a user with different gallery-wide permissions. For example, user 'Bob' should be a gallery administrator for one set of objects, but have edit-only permission for another set.
• You want to allow some users to upload any file type of any size, but others should only be able to upload .JPEG's that are less than 5 MB.

Gallery administration

To accommodate this change, the concept of a “gallery administrator” has been introduced. A gallery administrator can change settings for a particular gallery but has no rights to other galleries. She can add users and roles, but those accounts are restricted to the current gallery.

The previous concept of a site administrator remains. The site administrator has complete access to all galleries.

Creating multiple galleries

The desired gallery is now specified on the Gallery user control defined in the web page. For example, the Gallery definition in default.aspx now looks like this:

<gsp:Gallery ID="g" runat="server" GalleryId="1" />

To create a second gallery, just add a new ASPX page and specify a new gallery ID:

<gsp:Gallery ID="g" runat="server" GalleryId="2" />

The first time you load this page, GSP will automatically create the gallery and a default set of gallery settings. One of the first things you may want to do is check the media object path to ensure it is at a unique location. You *can* use the same media object path in multiple galleries, but note that updating an object in one gallery does not update the database record associated with the other gallery.

Example: Create a staging gallery

To create a staging gallery where you can prep objects before pushing them to the production gallery, copy default.aspx to create a second ASPX page called gallerystaging.aspx. Change the gallery ID to a new value (such as 2). Open this page in your browser – you don’t need to run the install wizard or compile any source code. Log in with any account with ‘Allow site administration’ permission and configure the settings as desired, such as disabling anonymous access and changing the media object file path. Synchronize or add your media objects and organize them as you wish.

I’ll assume the original page default.aspx is your production gallery. While in your staging gallery, use the move/copy function to transfer the items to the production gallery. Voila! You have just deployed your items to production.

Roadmap

My priority is to get a beta version of the DotNetNuke module released as soon as possible. There are still some odds and ends to take care of, like how to implement licensing, but hopefully nothing significant. If I didn’t have any distractions, I think it would be ready within a few weeks. But my development time has been split to support a few customers, and it is unclear how much time will be devoted to them in the coming weeks.

My best guess is that I will have the DotNetNuke beta out by the end of August. That should be followed relatively quickly with the release of GSP 2.4, which contains the multiple gallery feature I am talking about here, some bug fixes, and some great new properties on the Gallery user control that website integrators will love. I will also try to squeeze in some high-value, easy-to-implement feature requests.

Once the DotNetNuke module and 2.4 is out, I plan to implement those top features requests you have:

• Tagging
• Better upload experience – especially the ability to upload a compressed version of an image rather than the original
• Extract video thumbnails
• Advanced sorting
• Much more…

Issues with Visual Studio 2010

ACTION ALERT: See the end of this post for a request to vote on a Visual Studio bug that is affecting Gallery Server Pro development. I need your help!

UPDATE 2010-5-5: Microsoft has confirmed they can reproduce the issue and is investigating it. Keep voting to keep the pressure on!

Visual Studio 2010 just came out, so I installed it, opened up the Gallery Server Pro solution, and took a peak around. The first thing I noticed is that all my ascx and aspx pages had squiggly marks all over the place:

When I hover over the @Control directive in the first line, I see this message:

"ASP.NET runtime error: Could not load file or assembly 'System.Data.SQLite' or one of its dependencies. An attempt was made to load a program with an incorrect format."

That is a tell-tale sign that Visual Studio is trying to load the 64-bit version of System.Data.SQLite into its own 32-bit process. Kind of makes sense, but this worked fine in VS 2008.

This problem also seems to cause issues with custom user controls and third party server controls. For example, when I hover over the uc1 user control declaration (you can see it in the screen shot), I see this message:

"Unrecognized tag prefix or device filter 'uc1'"

I also lose intellisense on these controls.

Despite these problems in Visual Studio, these errors seem to be more cosmetic than a show-stopper. I can compile the solution and run it in IIS. It is annoying to lose intellisense and the squigglies are making me sea sick, but at least I can continue working.

If you are working with the Gallery Server Pro source code on a 64-bit operating system, you may run into this as well. Not a big deal, but if it drives you nuts, here are the known workarounds:

1. Use Visual Studio 2005 or 2008 instead.

2. Use a 32-bit OS.

3. If using a 64-bit OS and VS 2010, avoid IIS (which is 64-bit) and stick with the built-in Cassini web server (which is 32-bit). Rename the dll in TIS.GSP.Data.SQLite\assemblies\x64 to something else such as System.Data.SQLite_x64.dll (or delete it) and then recompile. This forces Visual Studio to use the 32-bit version of System.Data.SQLite.dll.

None of these workarounds are very attractive to me, so my best hope is for Microsoft to fix this in a service pack. To start this process, today I submitted a bug report with Microsoft. To make this a priority for Microsoft, I need lots of people to validate the issue and vote on it. So I ask for your help. Please go to the bug report and vote for it. Thanks!

New version adds features, support for .NET 4.0, and fixes bugs

The latest version of Gallery Server Pro fixes several bugs, adds a few minor features, and includes support for ASP.NET 4.0. Download it here. The Web Platform Installer version will be released in a week or two. There are no changes to the database schema, so upgrading is as simple as saving a copy of your web.config and galleryserverpro.config files, replacing the web files with the new ones (but don’t overwrite your SQLite database file galleryserverpro_data.sqlite), and then navigating to default.aspx?g=upgrade in your web browser. Detailed upgrade and installation instructions are in the Admin Guide.

Besides fixing over a dozen bugs, this version adds the following features. Below I dig into these in more detail.

• Includes support for running under .NET 4.0
• Added support for web archive files (.mht)
• Easier integration into other web applications
• Backup file now compressed in ZIP archive to enable faster download and uploads
• Files are guaranteed to be added in alphabetical order during a synchronization
• Automatically clear deleted users from album owner field
• Improved date parsing of image metadata

Support for ASP.NET 4.0

Gallery Server Pro can run under .NET 2.0, 3.5, or 4.0. By default it is configured to run under .NET 2.0 with MS Ajax 1.0 Extensions. Since 3.5 and 4.0 include built-in Ajax support, you do not need the MS Ajax extensions when running under those versions. The only change that is required to run under .NET 3.5 or 4.0 is a switch to a different web.config file. GSP includes several variations of web.config, as seen here:

There are six versions of web.config, but only one is necessary. Pick the one you need, rename it to web.config, and delete the rest. The versions with “sqlserver” in the name can be used in medium trust environments where SQL Server is the only data option. These have been purged of references to SQLite, which requires full trust.

For example, if you are installing to a freshly built server with .NET 4.0, rename the file web_4.0.config to web.config and delete the remaining config files. In this case, you do not need to have .NET 2.0, 3.0, 3.5, or MS Ajax Extensions installed.

Support for web archive files (.mht)

Thanks to a suggestion by a user, I added support for web archive files (.mht). These are files that contain web pages, including images, in a single file. You can create an MHT file by navigating to a web site in Internet Explorer and choosing the Save As… command. It is an efficient way to capture the contents of a web page at a single point in time, in a single file.

For example, I used Internet Explorer to save the home page of www.galleryserverpro.com to a file named gsp.mht and then I uploaded it to my gallery. Here is how it looks when viewed in Internet Explorer:

The MHT file is is displayed in an iframe. Notice how, even though it is a single file, it preserves the text, images, and styles of the original web page.

Unfortunately, only Internet Explorer can render MHT files. For other browsers, GSP gracefully degrades to a helpful message about your options for viewing it:

This feature was implemented entirely by adding a few lines of text to galleryserverpro.config. All I did was define the MHT file extension:

<mimeType fileExtension=".mht" browserId="default" type="message/rfc822" allowAddToGallery="false" />

…and then define an HTML template to display this particular MIME type. Notice how I define the default template and then another one for Internet Explorer:

<mediaObject
  mimeType="message/rfc822">
  <browsers>
    <browser id="default"
      htmlOutput="&lt;p class=&quot;gsp_msgfriendly&quot;&gt;This browser cannot display web archive files (.mht). Use Internet Explorer or download it by clicking the download link in the toolbar.&lt;/p&gt;" />
    <browser id="ie"
      htmlOutput="&lt;p&gt;&lt;a href=&quot;{MediaObjectUrl}&quot;&gt;Enlarge to fit browser window&lt;/a&gt;&lt;/p&gt;&lt;iframe src=&quot;{MediaObjectUrl}&quot; frameborder=&quot;0&quot; style=&quot;width:680px;height:600px;border:1px solid #000;&quot;&gt;&lt;/iframe&gt;" />
  </browsers>
</mediaObject>

The ability to create and edit HTML templates to customize the display of media files is a powerful one that really sets GSP apart from the competition. The Admin Guide has more information if you want to explore this feature.

Easier integration into other web applications

Gallery Server Pro no longer requires anonymous identification to be enabled at the application level. Previously, the web.config file enabled anonymous identification so that GSP could store user preferences for anonymous users.

In previous versions, a problem appeared when developers tried to integrate the gallery into an existing web site that was incompatible with anonymous identification. For example, Yet Another Forum throws an error when this feature is enabled. Since GSP throws an error when it is disabled, you were in a no-win situation.

Anonymous identification was only marginally useful to GSP, as I really only used it to keep track of whether the user had requested the image metadata popup window to be visible. Since I could easily handle this with a session variable, I refactored the code to use session to store this info for anonymous users. Logged on users continue to store user preferences in profile properties, just like before.

The most significant aspect of this change is that the web.config file for the web application no longer needs this line:

<anonymousIdentification enabled="true" />

The versions of web.config that ship with GSP already have it removed. If you have integrated GSP into an existing version, you should remove this line. Also, update the profile property ShowMediaObjectMetadata to disable anonymous identification:

<add name="ShowMediaObjectMetadata" defaultValue="false" type="String" allowAnonymous="false"/>

Other enhancements

I will quickly mention the remaining enhancements.

1. Backup file now compressed in ZIP archive. The Backup/Restore page in the Site Admin area now packages the backup file in a ZIP file before sending it to the user. Since the backup file is XML that is easily compressed, this creates a compressed file that is a fraction of the size of the original. You can restore with the zipped file, too, which is especially useful if you are on a network with a painfully slow upload speed.
2. Files are guaranteed to be added in alphabetical order during a synchronization. Most users discovered that files added during a synchronization were added in alphabetical order of the file name, but for some people the order seemed random. I added a specific step where I sort the list of files that are given to me by the operating system before adding them to the gallery. This should ensure media files are always added in alphabetical order.
3. Automatically clear deleted users from album owner field. This affects the small percentage of users who integrate GSP into an existing web site where users may be deleted by a mechanism other than the Manage Users page in the Site Admin area. For example, you might have implemented your own user management page. This change helps ensure data integrity.
4. Improved date parsing of image metadata. Gallery Server Pro is now a little smarter about handling partial dates in image metadata. I am referring to dates that contain only the year or only the month and year. For example, if you used Adobe Photoshop Elements to specify a picture was taken in 2007 – without specifying the month or day - GSP could not correctly read the date. This has been fixed.

Minor bug fixed by jQuery 1.4

I am surprised I didn’t notice this before or that no one reported it, but there is a small bug in 2.3.3512 on the Manage Users page in the Site admin area. To reduce information overload when user albums are enabled, only user-created roles are shown by default on the Roles tab of the Edit User dialog window, as seen here:

If you want to see ALL roles – including the ones created by GSP to manage security for user albums, then select the checkbox Show roles that support the album ownership and user album features. When you do, a little jQuery script runs that shows all of these roles. In this screen shot, two additional roles materialize out of thin air when the checkbox is selected:

Or at least it does in browsers other than Internet Explorer 8. When IE8 is in the default Standards Mode, selecting the checkbox does… nothing. Well, almost nothing. If the checkbox is selected and you close the dialog box and then make it reappear by editing the same user, the roles will correctly display. But that is hardly the desired behavior.

The first thing I did was download the new jQuery 1.4 release and try it out. As luck would have it, the problem is solved! Selecting the checkbox correctly toggles the visibility of the roles in all major browsers. Phew!

The next version of GSP will either include the latest version of jQuery or else it will link to the hosted one at Google. My current thinking is that it will default to the hosted version for performance reasons but you can always switch to a local copy if you want.

But you don’t have to wait for this fix. There are two ways to update your current installation of GSP to the latest jQuery library:

1. Download the latest minified version of jQuery and copy it to the gs\script directory in your GSP installation. As of today the file is named jquery-1.4.min.js. Then update the jQueryScriptPath setting in galleryserverpro.config to point to this file.

2. Even easier is to tell GSP to use the hosted version at Google. Open galleryserverpro.config and update the jQueryScriptPath setting to http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.js.

jQuery is a powerful library that helps make web pages come alive with rich interactivity. Currently I only use it in a few places in the Site admin area, but I plan to start using it throughout GSP. It will let us do some really cool things that previously I considered far too difficult to even attempt. Stay tuned!

GSP to be released as DotNetNuke module

The headline gives away the surprise at the end of this post, but first let me tell you what’s been going on.

I previously blogged about how I am taking a temporarily break from full-time work on GSP to restock the savings account through a programming contract. That started in August and looks like it will continue for a few more months. It has been a real bummer being away from GSP – it is so unsatisfying to have so many things I want to do but not enough time to do them.

Your support continues to amazes me. In the last couple weeks there were three $100 donations. I truly appreciate every gift and am doing my best to get into a position where GSP is self-sustaining. Ultimately I plan to bring developers on staff to speed up the pace of development.

Work on GSP continues, but at a little slower pace than when I was at it full-time. Each evening I have a go, beginning with catching up on forum threads. There are a couple things you can expect in the coming months.

SQLite support in the Web Platform Installer (WPI)

Microsoft included support for SQLite in Web Platform Installer 2.0, released a few weeks ago. I am working with them to create a new package that takes advantage of this. This will allow an even easier installation process for GSP because you can use the file-based, self-contained SQLite database engine rather than SQL Server.

As long as I am modifying the package, I am trying to add support for choosing the type of SQL authentication for SQL Server users. The current version requires that you use a SQL login account – support for Windows authentication is not supported. Sounds easy enough, but the Web Platform Installer does not appear to allow for this. I am waiting to hear back from Microsoft as to whether we can somehow shoehorn this in. If not, we’ll have to settle for SQL-only authentication for a while.

Bug fixes

There are a few bug fixes I’d like to get out, so I’ll probably refresh all the packages when the WPI version is released.

DotNetNuke module

Today I am publicly announcing that Gallery Server Pro will soon be released as a DotNetNuke module. You have probably heard of DotNetNuke – it’s the most popular Content Management System (CMS) for .NET. Below is a screenshot of a default DNN installation with the GSP module running in a page.

The module preserves all the features of GSP 2.3 while integrating with core DNN functionality such as user membership and site-wide searching. I am nearly done with the coding – just a handful of items left that I think will take about 40 hours or so to finish up. Finding those 40 hours is a real challenge, so I can’t provide a firm release date. I can tell you it won’t be within the next month, but I can also tell you that I want to get it out the door as soon as possible.

The module will be released as a commercial product, although no price has yet been set. The goal is that the revenue will pay the bills so that I can continue to offer the stand-alone version of GSP as a free open source product. Let me repeat – there are absolutely no plans to begin charging for the regular version of GSP. I adore the donation model and it is one of the things I am most proud of. That will not change.

If you are wondering why someone would pay for a module when they can have the regular app for free, I have thought of that, too. And I’m not worried. Developers who build DNN sites are accustomed to paying for modules that provide the desired functionality. They are typically building sites for customers who are paying good money and they don’t mind shelling out a few bucks to get what they need. Having access to the free regular version doesn’t really help them because it won’t integrate into DNN.

Stay tuned for more information.

Installing Gallery Server Pro Just Got A Lot Easier

I am pleased to announce that I teamed up with Microsoft to create a greatly improved installation experience using their Web Platform Installer. Installing GSP is now as simple as clicking a few buttons and filling out a few textboxes. No more manually creating the web application or wrestling with NTFS permissions!

Plus, GSP is also being distributed by Microsoft through their Web Application Gallery. Web traffic doubled the day this went live, and it has only increased since then!

The Web Platform Installer has two requirements:

• You must have permission to run the program
• You must use SQL Server to store the data

Those of you who use hosting companies that restrict you from running applications on the server – or who want to use SQLite as your data store – should continue to use the existing installation process. Support for SQLite will be coming soon.

I will step through the installation process to show you how easy it is.

When you click the installation icon (above or on the download page), The Web Platform Installer starts. If you do not have it installed, you’ll be prompted to install it.

Gallery Server Pro is pre-selected, so click Install. The installer determines which dependencies are needed. You list could include more than shown here.

Note that the installer will want to install SQL Server Express. If you already have SQL Server available on your network, you can skip installing it by clicking the X next to it.

When you click I Accept, the installation begins.

After your requirements are installed, the installer asks where it should install Gallery Server Pro.

Then it will ask for some SQL connection info. Remember that the installer supports ONLY SQL Server. Support for SQLite will be coming soon.

The installation is finished. Woo hoo! Look Ma! No messing with IIS Manager, Network Service accounts, or NTFS!

Click the link to launch your new gallery:

Pretty sweet, huh? This is a significant step toward making GSP easier to install and use. Microsoft has been very helpful and they deserve our thanks for supporting open source projects like this. And I look forward to spending more time adding features to GSP and less time in the forums explaining how to give the Network Service account modify permission to a directory. Cheers!