Tag Archives: visual-studio

Custom Component Depoloyment (ESRI) – better to use TARGETDIR

I think ESRI may be wrong on how to properly set up a custom installer for your custom dll’s for ArcMap etc.

How to deploy a custom component using a setup project


custom install


It’s basically implying that you should use:


Which translates to soemthing like “C:\Program Files(x86)\MyCompany\bin\foo.dll”

But this may not always be true, what happens when your user wants to install to a custom installation directory?  The ESRIRegAsm.exe tool will always fire against – C:\Program Files(x86)\MyCompany\bin\foo.dll, and not where the user selected to install! – it’s basically hard wired so that means your customers could have problems trying to install your software.  It’s better to use:


Which is basically the value you get back from this stage in the installation process (although it’s not very clear as you don’t see that as a variable in the properties window for this stage!):

install folder


This will then run ESRIRegAsm.exe against where the user decided to install your dll’s, properly installing the dlls into ArcMap etc.  This is, I believe more foolproof.  However if I have got this wrong, I’m happy to be proved wrong 🙂


Update to Visual Inheritance

After ‘writing off’ Visual Inheritance – I still found that I was stuck with it in my application – just so many things depended on it working.  I’m still annoyed about it being buggy and doing unexpected things – but I have come up with a list of things to do in order to keep VI ticking over – maybe you will find these useful too:

  • No abstract control types
  • No constructor arguments
  • Initialisation moved to Form_Load as opposed to the constructor
  • No controls nested in another windows control e.g. toolstrip.
  • Close all documents -> Clean -> Rebuild
  • Restart Visual Studio

I’ve just inherited visual crap!

I can’t believe Visual Inheritance is such a piece of crud! It does not work – simple as. This may be old news to some of you out there, but I think it’s worthy of a rant anyway. For those who don’t know what it is – well basically Visual Inheritance lets you create a form – lets call it your base form, and lets you inherit children forms from it or more specialised functionality of the base form. Its essentially a great idea, as this should potentially save you time if you design well.

If you don’t get the “One of more errors encountered while loading the designer…” blah de blah error message, then you cant get nested controls to work properly, like controls on the toolstrip etc. It’s just rubbish, especially when you spend time and effort into designing your code base to implement it.

Firstly – I am really annoyed at MS (Microsoft) – how could they release such fundamental flaws into a programming language, how did it get past formal testing? – it really dents your confidence in the product – but actually because I happen to like the framework so much, I have the inner strength to forgive them. But I’m still angry!

Secondly – In the past MS made voiced Visual Inheritance as a key feature of VS (Visual Studio) – they must have known that it was a bit dodgy but but put it in the release anyway.

Thirdly – MS even include it in the MS Certification exam (70-316). They are testing you on something that doesn’t work! – “I sense the conflict within you” (geek point for Star Wars type reference ;))

Fourthly – Be honest with us – tell us “we don’t recommend you use it”, we made a mistake and we can’t be bothered to rectify it. Now move on.

Finally – you shouldn’t have to be constantly fighting with the IDE designer, looking for workarounds and phantom errors that don’t really exist – its supposed to help us poor programmers – not toy with our patience and fragile emotions (well, at least mine).

So the final upshot is this – FORGET VISUAL INHERITANCE – Microsoft have!

You just have to do things the non-OOP way – it’s not as elegant, it’s more work, but at least you’ll be one step closer to delivering.