Look familiar?

Now where have I seen this before? :D

New Maestro Feature: Load Procedures!

If a picture is worth a thousand words. Then this post is worth 5000 :D

You may notice that some of the UI elements in the Transformation section are disabled. That's because these features are not supported in Maestro, and are ignored when the load procedure is executed.

The motivation for Load Procedure support was simply to satisfy the use case of "quick and dirty" loading of SDF/SHP files into MapGuide with default (monochromatic) layer styles.

I will be posting a 2.1 preview build soon that will have this and much more

FDO Toolbox is dead. Long live FDO Toolbox

This post is an official announcement that development of FDO Toolbox will be winding down.

The reasons for winding down are three-fold:

1. My original goals of FDO Toolbox have been met. With the exception of certain esoteric bits of the FDO API, my primary design goal of FDO Toolbox being a "front-end" to the FDO API has been effectively met.

2. I am taking over from Kenneth Skovhede as the primary maintainer of MapGuide Maestro.

3. Now being the primary maintainer, Maestro is now my primary focus. My long-term vision for Maestro is to have the data creation, querying, analysis and ETL capabilities of FDO Toolbox in addition to the publishing capabilities of Maestro, forming the ultimate tool for geospatial data. So to this end, you will see many parts of FDO Toolbox being merged into future releases of Maestro. So in a way FDO Toolbox will live on as part of the Maestro project.

Version 1.0 of FDO Toolbox, which will have the final version of FDO 3.5.0 will be the final release. After that, I'll be moving on full-time (my free time that is :D) to the MapGuide and Maestro projects and as a result, you'll be seeing more Maestro-related bloggery in the future.

R.I.P. FDO Toolbox (2008-2010)

FDO Toolbox v0.9.3

Here's a small point release with the following changes:

• Connections are now lazily initialized. That 100+ feature class ArcSDE schema will only take 5 minutes to load when you expand the connection node for the first time. All created connections are now initially collapsed.

• FDO has been upgraded to 3.5.0 RC1. The most notable feature of FDO 3.5.0 is the brand new PostGIS provider that is built from the same core as the other RDBMS providers. It is strongly recommended to use this provider (OSGeo.PostgreSQL) over the existing PostGIS provider (OSGeo.PostGIS). The existing provider is still included, but it should be considered deprecated and working with PostGIS data stores with this provider is discouraged. Please note that the express connection option still uses the old provider. You will have to use the generic connection method for the new PostGIS provider.

Download

Report bugs / feature requests

Coming soon to MapGuide Open Source 2.2

The problem stuck out like a sore thumb for the past 2 years, but as of the next release of MapGuide Open Source, Windows Server 2003 users can now choose the web site they want to install the MapGuide Web Extensions to!

Why did it take so long? Doing the custom action in .net would've been a piece of cake, but since we cannot afford the luxury of assuming the .net Framework as a mandatory requirement, we had to resort to doing the custom action in C++, which is no walk in the park. Thankfully, wcautil and IMSAdminBase provided the required tools to make this possible! Also, real world™ priorities had stolen whatever time I had to tackle this problem, until now.

Note that this applies to IIS6 only, as IIS7 uses a totally different form of configuration although we can still apparently use the same IMSAdminBase COM API, so if time/resource permitting I may be able to give IIS7 the same loving treatment.

Technical Question Etiquette

This post is a bit ranty, but I really need to get this off my chest.

On the same day where I lost over half a workday to some stupid Visual Studio problem, I had lost several more due to problems with another Microsoft product: IIS

The problem was that I had two IIS websites which weren't serving content. I did a check of the ASP.net versions and the host headers just to make sure nothing was misconfigured. I even rebooted said server to see if it would fix the problem to no avail. Event logs did little to help me, so with very few other options, I turned to the Oracle of Google for help.

Google was not kind to my pleas for help. There was only really one relevant result on the topic at hand, when I clicked on the result, the question pretty much was similar to mine. The only problem was, the reply to the question was from the original asker, which simply read:

Don't worry. I got it solved.

End of sentence. End of story.

I think as a general rule of etiquette, if you have a question and you somehow answered it yourself, please do tell us how you solved the problem because there may be others (like myself on that day) that have the same problem and would like to know how you solved it too!

/end rant

WPF + Geospatial Platform API = A recipe for failure

If you use WPF in your AutoCAD Map applications and you are using the Geospatial Platform API you may encounter something like this when designing any WPF content:

The type initializer for '<Module>' threw an exception.
at System.Reflection.CustomAttribute._CreateCaObject(Void* pModule, Void* pCtor, Byte** ppBlob, Byte* pEndBlob, Int32* pcNamedArgs)
at System.Reflection.CustomAttribute.CreateCaObject(Module module, RuntimeMethodHandle ctor, IntPtr& blob, IntPtr blobEnd, Int32& namedArgs)
at System.Reflection.CustomAttribute.GetCustomAttributes(Module decoratedModule, Int32 decoratedMetadataToken, Int32 pcaCount, RuntimeType attributeFilterType, Boolean mustBeInheritable, IList derivedAttributes)
at System.Reflection.CustomAttribute.GetCustomAttributes(Assembly assembly, RuntimeType caType)
at System.Reflection.Assembly.GetCustomAttributes(Boolean inherit)
at MS.Internal.ReferenceAssemblyUtils.SafeGetCustomAttributes(Assembly assembly, Type filter, Boolean inherit)
at MS.Internal.Xaml.ReflectionProjectNode.BuildNamespaces()
at MS.Internal.Xaml.ReflectionProjectNode.Find(Identifier namespaceUri)
at MS.Internal.Xaml.PrefixScope.FindType(XamlName name)
at MS.Internal.Xaml.XmlElement.FindElementType(PrefixScope parentScope, IParseContext context)
at MS.Internal.DocumentTrees.Markup.XamlSourceDocument.get_RootType()
at Microsoft.Windows.Design.Documents.Trees.MarkupDocumentTreeManager.get_RootType()
at Microsoft.Windows.Design.Documents.MarkupDocumentManager.CalculateLoadErrorState()
at Microsoft.Windows.Design.Documents.MarkupDocumentManager.get_LoadState()
at MS.Internal.Host.PersistenceSubsystem.Load()
at MS.Internal.Host.Designer.Load()
at MS.Internal.Designer.VSDesigner.Load()
at MS.Internal.Designer.VSIsolatedDesigner.VSIsolatedView.Load()
at MS.Internal.Designer.VSIsolatedDesigner.VSIsolatedDesignerFactory.Load(IsolatedView view)
at MS.Internal.Host.Isolation.IsolatedDesigner.BootstrapProxy.LoadDesigner(IsolatedDesignerFactory factory, IsolatedView view)
at MS.Internal.Host.Isolation.IsolatedDesigner.BootstrapProxy.LoadDesigner(IsolatedDesignerFactory factory, IsolatedView view)
at MS.Internal.Host.Isolation.IsolatedDesigner.Load()
at MS.Internal.Designer.DesignerPane.LoadDesignerView()


A nested exception occurred after the primary exception that caused the C++ module to fail to load.

at <CrtImplementationDetails>.ThrowNestedModuleLoadException(Exception innerException, Exception nestedException)
at <CrtImplementationDetails>.ThrowNestedModuleLoadException(Exception , Exception )
at <CrtImplementationDetails>.LanguageSupport.Cleanup(LanguageSupport* , Exception innerException)
at <CrtImplementationDetails>.LanguageSupport.Initialize(LanguageSupport* )
at .cctor()


Type constructor threw an exception.
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHR(Int32 errorCode)
at <CrtImplementationDetails>.DoCallBackInDefaultDomain(IntPtr function, Void* cookie)
at <CrtImplementationDetails>.DoCallBackInDefaultDomain(IntPtr , Void* )
at <CrtImplementationDetails>.LanguageSupport.InitializeDefaultAppDomain(LanguageSupport* )
at <CrtImplementationDetails>.LanguageSupport._Initialize(LanguageSupport* )
at <CrtImplementationDetails>.LanguageSupport.Initialize(LanguageSupport* )

Though you can still build and run the project, the WPF designer is completely hosed, all intellisense is lost and as a result, the WPF designer becomes a bloated version of notepad.

The reason that happens is because the Autodesk.Map.Platform.dll is actually just a thin managed wrapper to the unmanaged AcMap* dlls in your AutoCAD Map installation, so the WPF designer is actually trying to locate these dlls from either:

• The project's output directory
• Or, some special working directory that's defined by Visual Studio (where this is, I have no idea)

After 5 hours of sleuthing around, I have found an acceptable workaround.

Simply put the AutoCAD Map installation directory into your PATH environment variable and restart Visual Studio. The WPF designer will correctly locate the AcMap* dlls and you'll regain full designer functionality.

This little tip will no doubt be useful to someone out there. I lost 5 work hours so you don't have to :-)