Currently i create a commandline tool called RegAddin.exe – It is redestributable in installations and has more options as RegAsm.exe – specialy it comes with a feature to register and deploy an addin only for the current user without admin privileges(1). (It works also with Build events in visual studio to replace “Register for COM Interop”) With some WIX templates it was very easy to to deploy an addin -even for beginners- thats the idea.
It works so far but i still face some magic from RegAsm.exe i didnt understand – and there is no documentation at all how this infrastructure works. So i use the monkey-see-monkey-do principle in virtual machines and spend limitless hours each night to understand what are the rules behind.
Currently i have 2 Addins(AnyCPU compiled) on an 64 Bit system there totaly the same for me incl. its dependencies.
But for the first addin RegAsm.exe generate
@ = “mscoree.dll”
and for the second addin:
The second addin is redirected to Wow but not the first addin. I have no idea why for the moment…
Even in ILSpy/DotNetReflector i see no difference.
So thats what i do at the moment.
(1) Since Windows 7 it is possible to register an addin without admin privileges only for the current user. The HKEY_CURRENT_USER hive key spend some special subkeys to bypass HKEY_CLASSES_ROOT. But RegAsm.exe/Visual Studio(and most Intallers) can’t handle that.
Right now, i create new deployment tools for the upcoming NetOffice release.
One of them is a tool i call it “RegAddin.exe” – a substitute of “RegAsm.exe” with more options
and working without(!) admin privileges also in deployment and so on.
My main strategy in development was to replace the “Register For COM Interop” option in Visual Studio with RegAddin.exe and
the Pre/Post Build events. Unfortunately the PreBuild event in Visual Studio is running AFTER the clean command(which is deleting the former build assemblies i need to call the old former logic(incl. call the Unregister method) like RegAsm does the job to imitate the process as best i can). So i can not made an unregister process for the previous build assemblies. The internal “Register For COM Interop” option in Visual Studio has access to an internal event before Visual Studio cleanup the old assemblies. This is not fair!
I can level this problem easily(try unreg in the postbuild event BUT with the new assembly).
Developers may face an unexpected behaviour in a 1% percent case here in compare to RegAsm.
(And how i can explain this in easy words to semi-professional developers in documentation?)
“Kommt Zeit kommt Rat” (a german quote that say the answer comes in time)
Last night i give a message to codeplex about source control because my SVN connection doesnt works for 2 years. ( i can not commit any new code)
2 days later the answer comes from Xuefei Wang(Pactera Technologies) to told me we have issues and just wait please.
Pactera Technologies – A chinese company there want handle social support like indian-call centres(“tadorri chicken please”).
Here was the point i realize Microsoft realy left off Codeplex.
I want change the source to github now and keep handle discussions and issues on codeplex(as long it works)
*just my 2 cents
At the introduce of MS Office 2016 – the MS Product manager told us. “We did no changes because bla bla Marketing bla….(we dont care for this API anymore – is what he really means)”
Last night i take a deep look in the Office2013 and Office2016 COM API to to see it is realy the truth?
I’ve been compared Excel/Word/Outlook and PowerPoint in detail – with my own special tools there help me to create the NetOffice source code.
Ok, here it comes:
Yes – it is. No changes in Office 2016 COM API in comparsion to Office 2013.
No new types, no changed method, property signatures, no new enum members, nothing at all!
(no warranties for the implementation behind but Office 2016 API is definetily the same as its previous version)
[Edit: In a previous version i talk about Office 2015 instead of 2013. Thanks to officemacro.wordpress.com here]