Uffe
Yes using an installer is best, however during the development you don't need to go through the process of creating an installer until it is stable and/or ready to deploy to users.
As you state it's not too difficult, there are plenty of tutorials on creating a Wix installer, but some are confusing and may not relate well to the needs of an addin developer. For me it was remembering which stuff to include and where. Like you I soon produced a template that I use for creating virtually all my addins and their installers which is really useful, not least as a check list of what to include/where. However, I also saw little demand for AddIn or installer "helper" products - I even started writing a book on addins about 3 or 4 years ago but my interest waned when I saw there probably wasn't a market, so just keep a private wiki iof useful stuff instead.
Coming to the point you make about com registration and admin is interesting. I'm not a windows OS expert (too new an OS for me!) but had assumed that to make changes to the registry (at least in Win 7 onwards with GAC) you need admin rights.
It may be wrong or specific to my system(s), but I've seen some issues with VS when it hasn't been running as admin and failing to register a DLL. So worried that I imagined it I've just rerun a test (as a normal i.e. non-admin user), and on building one of my AddIns I got an error message:
Error 44 Cannot register assembly "C:\Users\NormalUser\Documents\Visual Studio 2012\Projects\eaForms81439\eaFormGenerator\bin\x86\Debug\eaFormGenerator.dll" - access denied.
Please make sure you're running the application as administrator. I remember this situation changed when I moved from XP to Win7. I had always assumed it was a consequence of how the OS GAC is configured. Never really explored it further, so just accepted I needed to ensure that EA wasn't running and I ran VS as administrator before I built my solutions.
Of course, my observations may not be typical, but I do feel there is more to it other than it isn't an issue of privileges or locks. Unfortunately it would take some time to understand all the rules and if there is an easier way....
As one of my colleagues always reminded me years (decades) ago "always work at the lowest possible privilege level" - but that also means spending time working out what is essential and what is nice to have. Easy just to work as an admin user.
Finally, coming back to the original reported issue, Stenvang hasn't indicated any error messages - so I would have initially discarded the saving of the DLL more about where the registry thinks the class is linked. So think getting the key information from the registry to see the mapping between EA and the class and the linked DLL file is key to getting a clearer understanding of the issue.
Adrian
