Beyond the Box

Porting AIMS Themeing to a New Oracle Environment

In one of the AIMS applications I work on, we allow our customer to do most of the themeing in AIMS. They are more than happy to set up exactly how they want the data to look and how the users will view and interact with it.  Because the customer does this themeing against a 'development' database and this themeing is later ported to the 'production' database that the application actually uses, sometimes the tables used for the development themeing may be named differently in the production database.

What these differences essentially mean is that you can't just export an AIMS .MGP package from the source environment and apply it to the ptroduction environment due to the differences in table names and schema names. If you open the Layer for editing within AIMS Studio and try to change the Data Resource or Feature Class, AIMS Studio will reset all your layer definitions…

There are two ways to get around this…

Editing the AIMS package

When you use the AIMS Site Administrator to create a package, the resulting file is <File Name>.mgp

This is in fact a ZIP file that contains all the Studio themeing in XML format. The steps I suggest for editing this file are:

• Take a backup copy first, in case you accidentally invalidate the package!
• Rename the file to a .zip (eg. before: My_Studio_Themeing.mgp After: My_Studio_Themeing.zip)
• Extract the zip file to a folder
• Drill down through the folder structures and locate the definition of the layer you wish to change. It should be something like this:
      <Layer Name>.LayerDefinition_CONTENT.xml
      <Layer Name>.LayerDefinition_HEADER.xml
• Open the 'CONTENT' file with a text editor (such as Notepad++) and make the required changes
  This is likely to be one or both of:
     <ResourceId>XXX</ResourceId>
     <FeatureName>YYY</FeatureName>
• Save your changes and close the file
• Re-zip the entire folder
• Rename the .zip file back to a .mgp

You can then import the package using the AIMS Site Administrator to establish the new environment with the correct definitions.

TIP: When the package has been unzipped, you can do a 'Find' in Windows Explorer to locate all occurrences of layers with the definition you wish to alter. You can then select and open all of these files in Notepad++ and do a global search and replace, followed by a 'Save all...".

Editing Layer definitions with MapGuide Maestro

There is an Open Source alternative to AIMS Studio called MapGuide Maestro. You can find it here: http://trac.osgeo.org/mapguide/wiki/maestro

I don't profess to know much about Maestro, however I do use it to edit the XML definition of my Layers. You simply start up Maestro and point it at your AIMS server. Then go to your LayerDefinition and right-click to choose 'Edit resource with xml editor'…

You are then able to make the required changes, again likely to be one or both of:
    <ResourceId>XXX</ResourceId>
    <FeatureName>YYY</FeatureName>

Make sure you save your changes, then open in AIMS Studio again to make sure the definition is correct by previewing your Maps!

Hopefully these steps will make a potentially tedious task that much easier.

Remote Debugging in ASP.Net with Reflector Pro, Part 2 - Regenerated Assemblies.

In my previous post Remote Debugging in ASP.Net with Reflector Pro, Part 1, I touched on a more complicated potential scenario where the assembly you want to debug does not have a debugger signature. This requires Reflector Pro regenerate the assembly before debugging is possible. And, a further complication occurs if the assembly is also strong name signed. None of this was explored in the previous post, so in this post I intend to show you how to deal with these situations and successfully debug such assemblies.

I should clarify here that this post continues on the specific scenario of remote debugging with an ASP.Net web server. While there are still portions of this post and the previous one relevant for debugging locally, overall debugging locally is far more straightforward.

By the way, if you're interested in a broader look at the overall topic, or just a bit of background to this post, take a look at the companion post Remote Debugging in ASP.Net with Reflector Pro, Part 1

Assembly without Debugger Signature.

"What's a debugger signature?" I hear you ask. The debugger signature in an assembly allows a debugger (e.g. Visual Studio debugger) to identify which pdb file is associated with each assembly.

An assembly can be built by Visual Studio with or without debug info. Setting Debug Info to 'none' results in no pdb file being created and no debugger signature written into the assembly. The Debug Info option in Visual Studio is in Advanced on the Build properties tab.

Strong Name Signed Assembly

If the assembly is also Strong Name signed, there's an additional (but not insurmountable) complication to deal with.

It's important to clarify here that the Strong Name signature is not the same as the Debugger Signature. Strong Name signing is a security mechanism by which the Common Language Runtime can determine if an assembly has been modified since it was built.

Clearly the presence of a Strong Name signature is important when Reflector Pro needs to rebuild the assembly to add a debugger signature. If an invalid Strong Name signature exists on the rebuilt assembly, the runtime will reject the altered dll and the application will fail to run.

Reflector Pro Wants to Rebuild the Assembly

So, here's the situation: You've identified that being able to debug code in a 3^rd party dll would be invaluable. After selecting the assembly in Reflector's 'Choose Assemblies to Debug' dialog, you receive a prompt to add a debugger signature and regenerate the assembly.

The example I'm presenting here is based on the release build of the open source log4net.dll assembly.

Reflector Pro forces you to click 'Set DEVPATH' so go ahead and do this.

The following message from Reflector Pro provides some background to the DEVPATH setting. However, setting DEVPATH on the local machine won't help with remote debugging, but go ahead and click OK anyway because this is the only way to enable the Regenerate button.

Now you can click the 'Regenerate' button.

After a few moments, Reflector Pro will have created the new dll and additionally produced a pdb file to enable debugging.

Note that the next time you open Reflector's 'Choose Assemblies to be Debugged' dialog, it will list 2 items for your chosen assembly, with only the rebuilt assembly being selected.

Remove Strong Name Signature

Remember the secondary issue regarding strong name signed assemblies that I mentioned at the start of this post? Well, if your assembly was Strong Name signed the signature verification will fail with the rebuilt assembly. If you use this assembly in your application as it is, expect an error page like this:

The solution is to simply remove the strong name signature so that we end up with an unsigned assembly. NirSoft has a free command line tool that performs this very task, aptly named SNRemove.

Using the –d switch, you can use SNRemove to display the strong name signature. In the command line output below, you can see the strong name signature for the rebuilt dll (before removing the strong name signature) has been set to all zeros by Reflector Pro.

C:\ProgramData\Red Gate\.NET Reflector\DevPath>snremove.exe -d log4net.dll

Strong name signature in log4net.dll:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The –r switch removes the strong name signature…

C:\ProgramData\Red Gate\.NET Reflector\DevPath>snremove.exe -r log4net.dll

Successfully removed the strong name reference from log4net.dll

Using the –d switch again to confirm the signature has been removed.

C:\ProgramData\Red Gate\.NET Reflector\DevPath>snremove.exe -d log4net.dll

log4net.dll doesn't contain a strong name signature.

Installing the Debug Assembly on the Web Server

Let's not lose sight of our ultimate objective: remote debugging.  There's an additional step we need to take to get there. Reflector Pro has created a new dll to use for debugging, and we've taken steps to ensure it will work, but it's still only on our local PC. We need to copy it to the remote server so that the ASP.Net application uses this alternate dll while we are debugging.

We only need to use the alternate dll temporarily, so keep a copy of the original dll so you can restore it later. In this example, I've added '.ORIGINAL' to the filename of the original file, and then copied in the rebuilt dll.

All Done! (well, almost)

Everything should now be in place for you to attach your debugger remotely and successfully step through the code. I won't go into details here because it's all covered in Remote Debugging in ASP.Net with Reflector Pro, Part 1.