November 2, 2011

Remotesoft protector is one of the best code protection tools out there. In fact, its pretty much the only one that really works. Since I moved to .NET 4.0 I’ve been getting an annoying error when attempting to protect my binaries using the 4.0 suite of tools (with the updated protector runtime). Everything still runs – it just pops up nasty alert boxes on load which is no good

One other symptom of this was that .exe files would just blow chunks. I’ve finally figured out what was causing this! Most of our products are protected during the nightly builds. This error however is specific to assemblies protected using the the Remotesoft .NET Explorer UI. When using this application for the protect or obfuscate functionality it is really just a front end around the protector.exe/obfuscator.exe. The UI is building the following command line string and tonight it finally dawned on me:

The UI was forcing the clr version to .NET 2.0 – when my assemblies are all built against .NET 4.0. Oops…

After a bit of digging I found that you can set the CLR version in .NET Explorer from the Action / CLR Version menu item. Unfortunately it has not been updated to support .NET 4.0 – and so has been rendered pretty much useless as a front end for protector.

The Fix

The only solution is to use the command line to execute your protection. The updated command line ended up looking pretty similar:

October 28, 2011

A friend asked me recently if there was some way to control the active AutoCAD ribbon tab from a macro. After a little bit of digging I could not find any lisp or command line command that would do this. ObjectARX however does provide the functionality I needed so I decided to whip something together in c#. I’ve named it RibbonNinja – because lets face it, ninjas are awesome and should play a much larger part of everyday life.

How’s it work?

Attached is a zip file that contains the dll. To use this simply netload the dll into your AutoCAD session and issue the all powerful RibbonNinja lisp call. It takes a single string parameter that is the name of the tab you want to activate. If it finds and activates the tab it will return T, if not it returns nil. For example given the following AutoCAD ribbon:

Issuing the following lisp statement will change the active tab from “Map Setup” to “Analyze”. Then it would switch to “Home"

1: (RibbonNinja “Analyze”)

2: (RibbonNinja “Home”)

This code is not case sensitive. If its even possible to have multiple menus within AutoCAD with the same spelling but in different cases you’re probably S.O.L. and it will always choose the last one. I’ve assumed unique tab names.

This dll has been compiled to work against AutoCAD 2012. It will support both x86 and x64 versions. It should also work on any AutoCAD vertical (i.e AutoCAD Map, Civil, ADT etc etc). If you get the following error when you try to netload the dll we have one last change to make:

Cannot load assembly. Error details: System.IO.FileLoadException: Could not load file or assembly ‘file:///C:\Program Files\Autodesk\AutoCAD 2012 – English\RibbonNinja.dll’ or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0×80131515) File name: ‘file:/// C:\Program Files\Autodesk\AutoCAD 2012 – English\RibbonNinjadll ‘ —> System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch.

Please read and try the following posts. .NET 4.0 is “protecting” us so we need to fix that. First you can try and “unblock” the dll following the steps outlined on Scott Sheppard’s blog. If that doesn’t work for you again shut down AutoCAD and edit your acad.exe.config file as explained by Kean Walmsley on Through the Interface. Remember to run notepad or whatever editor you’re using as an administrator – or you will get permission errors when you try to save the config file.

Turn up the nerd

For those of you more technically inclined the source is pretty simple once you figure out the mess of references that are needed:

August 9, 2011

Even though it’s the year 2011 and ObjectARX is available in all its glory for .NET I still spend a lot of time in the Visual Lisp IDE (VLIDE). While ObjectARX is powerful and full of awesome, it comes at a cost of a lot of overhead to setup a project, add all the needed references, heck even compiling / debugging is a huge pain in the ass in comparison to Lisp. Lisp is still hands down the most efficient way to do most batch modifications within an AutoCAD session for those who have made the time to learn it.

There are a couple of problems with Visual Lisp right now though. One of my biggest complaints about the VLIDE is the default colors. The high contrast white background is an eye killer. The IDE is configurable though and we’re given full a 16 bit color palette – with which I was able to configure a color scheme that was more to my liking. If you start Visual Lisp, go to the Tools menu and choose Window Attributes you are presented with the dialog that should let you configure your colors. Before opening this configuration dialog select a code window in Visual Lisp to modify. Set the properties accordingly. If you are happy with the colors when you press Ok on the dialog you will be prompted to “Use current as EDITOR prototype?”. Clicking yes here will update you editor prototype, resulting in future windows using these defaults.

One key limitation here is that on x64 editions of AutoCAD this dialog is broken. You may also see the following error when you attempt to close the dialog:

**Update May 11th 2012 – This appears to have been fixed in AutoCAD 2013 x64. Hurray!

It seems that Autodesk has let this code go to some extent. I’ve seen a number of forum posts of people mentioning the unwind error. This is a shame and partly why I’m writing this post! First off – if you have an x86 release of AutoCAD you are in luck. You can configure your IDE no problem using the UI. For you x64 users, all is not lost. Lucky for us Visual Lisp saves all this configuration information to a text file named VLIDE.dsk. On my Vista x64 machine its found in the following locations:

If you open up this file you’ll see a large list of dotted pair lists full of settings. The one I’m most interested in here is the *editor-sample-window property. This is the “default” configuration to use when opening a lisp file.

Two values of importance are FGC (foreground color) and BGC (background color). I was having a hard time finding a color wheel that did integer based color codes – but you can convert your favorite hex color codes to decimal (helpful hex to decimal converter here). The next bit is a little ugly. Within the :CLV property we have a list. This list is basically a list of 16 bit integers containing a color code of the foreground and background color of each window property. If the color is set to nil – it is transparent. This list appears to be in the order in which the properties are displayed within the UI:

:LEX-SPACE

:LEX-STR

:LEX-SYM

:LEX-NUM

:LEX-INT

:LEX-REAL

:LEX-COMM

:LEX-COMM1

:LEX-COMM2

:LEX-PAREN

:LEX-SPEC

:LEX-SPEC1

:LEX-UNKN

:WINDOW-TEXT

:WINDOW-SELECTION

:ERROR-HIGHLIGHT

:INPUT-ZONE

:CONSOLE-MESSAGE

TW and LM contain the tab width and left margin respectively. So go wild editing these values and configure your new IDE! Keep in mind when editing the Visual Lisp settings using the UI, the vlide.dsk file is not saved until AutoCAD is shutdown cleanly. If AutoCAD crashes, you will lose your configuration. If you would like to try out my IDE settings – I’ve attached a zip file containing a copy of my .DSK file. I also recommend you make a backup of the .dsk file before you start tinkering.

Now, if only I could figure out some way to build a vlx file from the command line so as to integrate it into my automated build system..

For those of you who don’t read the comments – Dennis Hill was cool enough to share his digging into the DSK file and also his IDE colors which I’ve been running for a week or so now. Take a minute to read the comments and check out his color scheme. Thanks Dennis!

March 22, 2011

While attempting to work out some x64 specific kinks in some of the DraftLogic COM code that is being migrated to .NET I hit a pretty annoying wall. Well, it was actually a series of small walls (probably around knee high) that kept tripping me…

In this post, I’m working on a problem that is pertaining to a 64 bit version of AutoCAD loading a COM enabled .NET assembly – however this information should apply to any x64 executable calling any x64 COM assembly. Replace AutoCAD with <YourApp.exe> and you should be good to go =)

The first thing I did was to ensure each of the projects had been set to build for “ANY CPU”. This got the ball of fun rolling. We have a VLX which instantiates the COM class using vlax-get-or-create-object. When called this would constantly return nil. Of course this all works just peachy when running an x86 build of AutoCAD. At this point my breakpoints would appear in Visual Studio as disabled and would happily inform me that “The breakpoint will not currently be hit”.

This usually results when the incorrect DLL is being loaded, or when the PDB file is missing. Once Visual Studio is running in debug mode you can bring up the Modules window from the Debug/Windows/Modules menu. This should show you all the assemblies involved in the current session as well a bunch of other information including their paths. The assembly in question was not listed here – so at this point I’m assuming that Windows cannot find the dll.

Junk in the Registry

I am now thinking that I have orphaned and duplicated types and CLSIDs in the registry, likely pointing to other builds of the dlls. If the GUIDs for the classes or types changed you end up with a lot of junk in the registry. I don’t trust those registry “cleaner” apps and in the interest of keeping my OS working – I chose to manually search out and nuke all the registry references manually. This can be done by searching both for your assembly’s type name, and COM exposed class names in regedit. A lot of this was done in the HKEY_CLASSES_ROOT root. After all of that the problem still exists..

Wow6432Node Registry Keys

Registry keys were a two part problem. After dealing with the junk in the registry, I found I also had to deal with the x86 registry redirection. DraftLogic has been until this point limited to x86 architecture as a result of the VB6 code not being x64 friendly. As a result of this, all of the needed keys had been placed in the WOW6432Node of the appropriate software registry sections. This was the easiest wall to find and hop over. Unfortunately, this also didn’t solve the problem.

Improperly Registered Assemblies-thanks for nothingVisual Studio

So the next and fortunately final problem turns out that Visual Studio 2005/2008 (unsure about 2010) does not properly register assemblies. Turns out the last piece of the solution is pretty simple – couple changes to the project. What’s happening is that Visual Studio is running the x86 build of regasm.exe to register the assemblies on run, probably because Visual Studio is an x86 app itself. This results in all kinds of x64 hating… To solve this we have to change two things in the COM enabled projects.

First though, I created a new build configuration called x64 so these changes would not affect in my ANY CPU configuration – which will be used to build my shipping assemblies. It is also important to note that this problem is MOSTLY only a problem when running code from the IDE. Assemblies installed and registered using an installer should not have this problem if the installer takes into consideration the “bitness” of AutoCAD (or any application calling your COM enabled dll). ie. Installshield asks the user on install what “bitness” of AutoCAD they are using, and the assemblies are registered as needed. It may also be possible to register an assembly using both the 32 and 64 bit versions of regasm – but I have not tried this.

So with the new x64 configuration created I edited the properties of each COM enabled project I unchecked “Register for COM interop” and added a post-build event command line of:

This would ensure that my COM enabled assemblies were properly registered for use by 64 bit applications.

After all that, my breakpoints were finally hit, and I could actually start working out the x64 specific bugs. Too bad we couldn’t have moved this to ObjectARX.NET instead – then this would have been a non-issue =) In retrospect, each of these problems were a contributing factor and each needed to be resolved.

Hopefully if you are facing a similar issue this post helps you get over at least a couple of the walls!

March 9, 2011

Finally had a little time to catch up on the internets today and came across this post on ReSharper 6 bundling a decompiler! My curiosity had been piqued by a little tease posted by JetBrains shortlt after the announcement by Red Gate about reflector and the subsequent firestorm in the .NET community that ensued that announcement.

The timing is perfect. We’ve got a growing need to better understand how some of our code is interacting with some vendor provided 3rd party libraries and this is making a huge difference. In true ReSharper form – this new functionality looks solid, and easy to use. The ReSharper navigation tools we’ve all grown love (well maybe not just love, but also to depend on) are available. I’m not going to miss trying to navigate code only to be greeted with an Object Browser window. ..

Looks like a standalone decompiler/browser is also coming too…

And by saying “free”, we actually mean “free”.

Love it! Keep up the great works JetBrains – looking forward to the release!

February 24, 2011

I’ve been working on supporting the team doing the DraftLogic VB6 code migration to .NET the past few weeks. This code is many years worth of COM based AutoCAD development. Came across this excellent link that will give you a good head start in the right direction on which functions are the new equivalents in .NET of the old VBA/COM calls.

February 14, 2011

I encountered the following error when trying to debug a new ObjectARX .NET assembly using Visual Lisp.

Attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain or image initialization function since doing so can cause the application to hang.

This error would occur 95% of the time and pretty much took out AutoCAD each time it happened. Fortunately this can be disabled pretty easily within Visual Studio (I’ve tried both VS 2008 and VS 2010). In Visual Studio bring up the exceptions dialog from the Debug / Exceptions menu (or via the keyboard shortcut Cntrl D+E).

Expand the “Managed Debugging Exceptions” section and uncheck “LoaderLock” in the “Thrown” column. Next time you start AutoCAD from Visual Studio and load Visual Lisp you should no longer get this exception and you should be merrily debugging away.

November 6, 2010

Working on the automated build process for FullCircle SmartForms tonight and I came across an irritating problem tonight:

"ERROR: Unable to update the dependencies of the project. The dependencies for the object ‘NHibernate.Validator.DLL’ cannot be determined."

One of my three Visual Studio 2010 installer projects started failing during the automated build process with this error on a dozen included assemblies. When the project was built using the Visual Studio IDE the installer would build just fine. With a little bit of digging and a great deal of screwing around, I found a Microsoft KB article and hotfix for this problem.

After installing the patch – my automated build system is happily compiling the installation project.

First, download the actual non-aplha release of LINQ to XSD and extract it. You will need to have .NET 3.5 installed to run LINQ to XSD. The project itself is a Visual Studio 2010, .NET 4.0 project. You should be able to change it to .NET 3.5 with no problems. I’m not sure about using .NET 2.0. I still assume these steps should work with Mapguide Open Source 2.2 given its pretty much the same thing as MGE 2011. Please let me know if you try it and that is not the case.

Building the classes

Last time around we had to mess around with Visual Studio projects, building temporary code, finding and extracting that code from temporary files. This time around, we’re given a nice little executable that can be run in a batch file. I’ve posted a copy of my batch file below but it was simply made using a dir /b > CreateMapguideNetObjects.cmd in the Mapguide server schema folder (which by default is to c:\Program Files\Autodesk\MapGuideEnterprise2011\Server\Schema) . I then edited that file with a text editor that support macros and removed the following schema files:

FdoProviderCapabilities-1.0.0.xsd

LoadProcedure-1.0.0.xsd

LoadProcedure-1.1.0.xsd

LayerDefinition-1.0.0.xsd

LayerDefinition-1.1.0.xsd

LayerDefinition-1.2.0.xsd

SiteInformation-1.0.0.xsd

SiteVersion-1.0.0.xsd

SymbolDefinition-1.0.0.xsd

WebLayout-1.0.0.xsd

These files are deprecated object definitions from previous Mapguide releases. In the end each line in the batch file looks a little like this:

Executing the batch file will create a number of C# files containing appropriately named classes.

Setting up your project

At this point you should be able to fire up Visual Studio and create a new C# project. If you have an existing project from a previous version of Mapguide its good to start fresh. Also, don’t try this in an existing solution that is dependant on the project that contains the Mapguide objects. This will just result in a bunch of extra screwing around to avoid compiler errors from missing code during the process. This time around its a lot easier. Create a new DLL project. Add a reference to the Xml.Schema.Linq.dll file that was included with LinqToXsd.exe. Add a reference to the following Mapguide dlls:

OSGeo.Mapguide.Foundation

OSGeo.Mapguide.Geometry

OSGeo.Mapguide.MapguideCommon

OSGeo.Mapguide.PlatformBase

OSGeo.Mapguide.Web

You’ll also need to ensure that the appropriate unmanaged assemblies are available in the calling applications bin folder when you go to run this stuff.

Next place all of the generated C# files in the new project. Once you build you’re going to see a ton of errors. We’ll clean those up.

To resolve a lot of these errors I did a global search and replace on “global::” and replaced it with nothing. Also, I wrapped each class in a unique wrapper classes to prevent duplicate type errors. Finally, the case issue with DataType was still an issue – and I resolved it by changing the case on DataType to be Datatype:

1:publicstring DataType {

2:publicstring Datatype {

For a complete view of the changes I made do a file compare between the code in the attached zip file and your newly generated code.

And back. The best part about this is that it seems ALL my old RADE code just worked with upgraded basic layouts after changing it to look for the object definitions within the new wrapper classes. Now I just need to add support for flexible layouts and we’ll be laughing.

The Code

Please note – I didn’t rebase the code. It’s all in the RADE.MGE namespace. If you would like to use it, feel free to re-base it – or just leave it as is. Also, if you create any unit tests or enhancements and would like to share them – please feel free!

As I update the project myself, or receive updates I will update this file.