Robert: There are two competing problems here. First, the krbcc32.dll and krbcc32s.exe are bound together. There is no guarantee that a krbcc32.dll will work with another krbcc32s.exe instance. In fact, when the new CCAPI server that Kevin created is on the same machine as a KFW 3.2.x CCAPI dll they will not communicate. So it is crucial that the dll and the exe be shipped together and that the dll only startup a copy of a server that it shipped with.
On the other hand there is this prohibition against including executables within assemblies. As you point out, SxS assemblies should not be invoked by applications by full path. This is to permit assemblies to be installed in any location that Windows (or the administrator) deems appropriate. However, that does not prohibit an assembly from accessing its own components by path. What the CCAPI library needs to do is resolve its own path and then use that to execute the server component with CreateProcess. Jeffrey Altman RJ Silk wrote:
Hi Jeff,I’m working on integrating/testing the merge module configurations with the build scripts Kevin was working on before he left. I’ve successfully built and installed the single-assembly (for testing) merge module described in your proposal, but I’m having a little trouble figuring out how I should go about modifying the CCAPI code to execute the credential cache server from the SxS assembly cache. In my testing, it doesn’t seem like CreateProcess(Ex) can resolve SxS executables (even when they reside in the same SxS assembly), and Microsoft says SxS assemblies should not be manually invoked by full path. Were you able to successfully load the server from the cache in your testing? Did you envision having a copy of the Krbcc32s executable sitting outside of the cache as well?Thank you! -Robert Jeffrey Altman wrote:Asanka Herath of Secure Endpoints has spent the last couple of months developing and prototyping a proposal to use Windows Side-by-Side Assemblies and Merge Modules as a means of distributing the core KFW libraries. The goal is to permit the core libraries to be installed along side third party applications that link to them in exactly the same way that the applications distribute redistributable components from Microsoft.The proposal can be obtained at http://www.secure-endpoints.com/kfw/proposal-kfw-assemblies.htmlPlease note that this proposal will require changes to the core libraries to permit multiple versions of the libraries to be installed on the same machine at the same time. If adopted, all distributions of the KFW libraries will have to be digitally signed, the minimum supported development platform would be Visual Studio 2005, and the minimum supported operating system version would be Windows XP.Feedback is welcome. Jeffrey Altman Secure Endpoints Inc._______________________________________________ kfwdev mailing list kfwdev@mit.edu http://mailman.mit.edu/mailman/listinfo/kfwdev
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ kfwdev mailing list kfwdev@mit.edu http://mailman.mit.edu/mailman/listinfo/kfwdev