Doodle Graphics

Ok, this one's pretty easy really, Initially we were just running with Stefan Großner's tips and code samples for using friendly URLs everywhere, and his hints on How to enable AJAX with MCMS and ASP.Net 2.0.

This was generally working fine for us, the page was requested by the ScriptManager calls, the ScriptManager in the master page hooked into the request, read the query strings it was looking for, rendered out the correct JavaScript, and stopped the page execution - all as you'd expect.

However, as development of the site progressed, we then built a control that allowed us to show or hide its child controls based on whether a MCMS placeholder on the posting contained any content - for example, we have an article page that can optionally display an image, and the image can optionally have a caption appearing below it - if there's no image, then everything under it should naturally float up the page, and the same for no caption. As there's a certain amount of html and css needed to get this to work, it's nicer if this isn't rendered out if there's no image, hence this control. However, to get this to work properly, with nested conditional controls, we needed to do our magic in the AddParsedSubObject method which runs before the ScriptManager did it's stuff - and if you try and call the posting templated directly without a CMS context (all those NR querystrings) and then try and access the CMS objects it all goes belly up.

Thankfully, there's a simpe solution - the ToolkitScriptManager that is part of the ASP.Net AJAX Control Extensions has a very nice property on it: CombineScriptsHandlerUrl - by default the ToolkitScriptManager will attempt to combine all the required scripts into one nice big script, instead of lots of little ones - and this property tells it what page it should call to do this - I think technically you should use an .ashx page for this - although an .aspx page with the ToolkitScriptManager on it works just as well - there's some detailed information on the CombineScriptsHandlerUrl here. Setting this property to a non-CMS page has fixed all our problems.

Another nice feature in ASP.Net 3.5 is the ScriptManagerProxy - this allows you to place a ScriptManager (or ToolkitScriptManager) on your master page and then place the ScriptManagerProxy in the page or user control as required. This means that to register a client script block instead of writing something like:

var scriptManager = ToolkitScriptManager.GetCurrent(Page);

if (null != scriptManager)

  { scriptManager.RegisterClientScriptBlock([...]); }

You can just call the local ScriptManagerProxy with the same methods. All very nice.

Part of the Series: The joys of using .Net 2.0, .Net 3.0 and .Net 3.5 with MCMS

Filed under: AJAX, ASP.NET, MCMS

This is I guess a prequel to the first post in the series "The joys of using .Net 2.0, .Net 3.0 and .Net 3.5 with MCMS", as after posting that, I receieved the following question:

"As I read the entry you seem to use Visual Studio 2008 with an MCMS enabled site. I've not been able to get that to work. How exactly did you do that?"

Well, here finally, is the online version of my reply (the reply was more timely than this),

As you know, with Visual Studio (VS) 2003 you could work with MCMS in a nice connected way; if you installed MCMS on the same machine as VS you would have access to some extra projects: "MCMS Web Application", "MCMS Web Service" and "MCMS Empty Web Project". These projects would do a couple of things for you:

1. Add the references to the MCMS libraies, and enable the MCMS placeholders in the toolbox
2. Add a line to the project file indicating that this was an MCMS project

As an MCMS project, it was hooked up to the local instance of the MCMS database and the Template Manager window in VS was enabled alongside the other docked windows like Solution Explorer.

Generally, our development environment has been that our desktop machines run a standard workstation operating system (typically Windows XP), and then we run various virtual servers with server operating systems that replicate the client's live environment - as VS won't be installed there, it makes sense not to have it installed in development - less chance of the incorrect settings filtering through - so we run VS on the workstations.

As VS runs on a separate machine to MCMS, we found that we had issues with the integration aspects - opening projects would take a long time as connections to the database were sorted out, and as our workstations were upgraded, the chances of having MCMS installed locally minimised.

We therefore tend to work with a standard Web Site/Web Application project (we've stuck with Web Applications as it makes deloyments slightly easier - one dll instead of all those .cs files - but for the initial prototyping of my last project I was using a Web Site to make buildling/debugging faster - MCMS worked fine under both).

You can easily add the MCMS controls to the VS toolbox as you would any other controls for design time creation:

1. Right click on the toolbox, "Add Tab" and give it a suitable name ("MCMS Controls" or something).
2. Right click on the new tab, "Choose Items...", navigate to the MCMS DLLs ([MCMS Install Folder]\Server\Bin\) and open "Microsoft. ContentManagement. Publishing. Extensions. Placeholders.dll" and pick the controls you want from there.

You can then build your site as you would any other site, creating master pages, .aspx pages and .ascx controls with whatever placeholders you need.

We would then hook up these pages using Steve Walker's "Template Manager" to create and edit our template definitions - this basically wrapped the Template Manager window from VS in a standalone application - I wasn't able to find it online when I looked recently - it was on GotDotNet, and probably died with the site.

The only other thing to be aware of is that Site Manager requires the Visual J# redistributable to run - and that this hasn't been updated beyond .Net 2.0

The two senarios here are:

1. Site Manager is already installed before you upgrade to .Net 2.0 +
   As the .Net 3.0/3/5 applications actually still run under the .Net 2.0 runtime, the simplist option is to download and install the Visual J# 2.0 Redistributable. If you don't want to do that, you can create a .config file next to the Site Manager executable ([MCMS Install Folder]\Client\NRClient.exe.config) with the following contents:
   <configuration>
  <startup>
    <supportedruntime version="v1.1.4322"></supportedruntime>
  </startup>
</configuration>
2. Site Manager is not installed, and you've already installed .Net 3.0+
   This is slightly trickier - the installer complains that you need the Visual J# .Net Redistributable package version 3.5 installed - which is impossible as there isn't a version beyond 2.0. Basically the installer is looking in the registry for the highest version number under:
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP
   If you rename the v3.0 and v3.5 keys, all you need is the version 2.0 redistributable installed, then you can install Site Manager, and finally rename the keys back

Happy coding.

Part of the Series: The joys of using .Net 2.0, .Net 3.0 and .Net 3.5 with MCMS

Filed under: ASP.NET, MCMS