Never thought of going to MSDN these many times

I am working on a project that uses quite a few C# APIs. For the audience of this blog I would have never imagined mentioning C#. But, its a good language and has its advantages for those who are using it. I came across a scenario when the option was either to rewrite the APIs in Java or reuse it. To mitigate the risk I decided to reuse it and invoke the C# API in Java through JNI. As it turns out C# API needs to be wrapped around two layers of C++ - First a Managed C++ and then another C++ wrapper to generate the dynamic library (DLL) that can be loaded and used by JNI. Came across another rather bizarre problem, that due to a reference to C# API (Some .NET Security requirement) the DLL has to be in the same directory as its invoker. My invoker is java.exe and for this thing to work this DLL has to be copied over to $JAVA_HOME/bin directory. Even though not a show stopper but this defeats the entire purpose of good deployment practices. One of my colleagues at the Clients who brings in a lot of .NET experience to the team pointed me to GAC (Global Assembly Cache) that can be used to address these issues. A few more MSDN pages to the point that I don't even care of using it. And as GAC requires administrative accounts I am even more disinclined of using it. Not because I do not have an administrative account but my dislike of products that only work when you have one. In the meantime while the colleague researches other options of by-passing the java.exe and dll co-location I am happy to take a shot to sell the idea of it.