Hey Eric, Shared Libraries... there are two answers to this question. First, just in case you're not aware Assemblies can technically be more than just DLLs. An Assembly can be collection of files-we typically think of them as DLLs because the OS supports finding and loading DLL Assemblies really trivially. If there are resource files associated with a shared library DLL, we can include them in the assembly. The only trick with that is that the DLL itself needs to know that it's 'resource' files are stored where it is stored itself, and should find out its own path so it can find them. Doing that may require small patches when we shallow-fork the project.
On the other hand, and I think that a shared library *could* have non-assembly files associated with them, and placed in a directory (c:\apps\.installed\CoApp\<foo>-1.2.3.4-x86\<foo's files>). The lib files aren't signed. The import libraries for shared libraries are treated just like static libraries, and should be built using a 'developer library' role. Yes, all *shared libraries* (assemblies) in the same MSI must be signed with the same cert as the MSI itself. You won't need to sign the assemblies, but you'll need to check they are signed correctly (with the same cert). As a matter of fact, all PE binaries in CoApp packages must be signed-however, if they are private DLLs (ie, placed in the App directory) they don't have to be signed with the same certificate-they could be libraries that the publisher has licensed from another publisher-but they do have to be signed. As for how to access the certificates... hmmm. In the short run, let's assume they are coming from a pkcs7 (.pfx) store -although, that won't be the only way. G From: coapp-developers-bounces+garretts=microsoft....@lists.launchpad.net [mailto:coapp-developers-bounces+garretts=microsoft....@lists.launchpad.net] On Behalf Of Eric Schultz Sent: Friday, August 20, 2010 9:05 PM To: coapp-developers Subject: [Coapp-developers] A few more questions... Hi everyone, hope your weekend is starting well. I've got a few questions for the group. - With a SharedLib will there ever be a file with that role that is NOT part of an assembly? For example, let's say we are installing a package to c:\apps\.installed\coapp\python\2.6.1.1. In this folder, we have two assemblies (with shortened names for ease of explanation), assm_x86.dll (and a manifest and cat file and any other files it needs) and assm_x64 (and a manifest and cat file and any other files it need). Will there ever be a situation where there will be files (not sub-folders) in c:\apps\.installed\coapp\python\2.6.1.1 that belong to NEITHER assembly? -Do .lib files need to be signed for inclusion in a CoApp package? I'd assume yes but I don't think I've ever heard of .lib files being using in a SxS assembly. -Do all the assemblies in a package need to be signed with the same certificate as each other and with the package MSI itself? -How are we planning on passing in certificates? Will we expect them in files of some sort and if so, what type (.pfx, .cer, .p7b)? Will they get them from the Windows Certificate Store and if so, how? Thanks for any help you can provide. Eric
_______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
