G
Gary McGill
Hi,
I have a managed-code shared add-in for Word/Excel/PowerPoint 2003 developed
in VS.NET 2003. I'm using the "shim" solution as described on MSDN. However,
I'm having trouble signing it so that it can be run on a machine with
security set to "very high".
My project consists of a dozen c# .NET DLLs plus the C++ shim DLL. All the
..NET DLLs are strong named.
I reckon that I need to sign all 13 DLLs rather than just the shim, yes? (I
tried signing just the shim, and that didn't work).
To sign all the other DLLs, I added a post-build step that does the signing.
So far, so good. When I build my project, all of the DLLs are signed. To be
explicit: in the C++ project, the DLL in the Release folder is signed; in
all 12 of the .NET projects, the DLL in bin/Release folder is signed.
However, I notice that for those .NET projects that have references to other
..NET projects, there's a copy of the referenced DLL(s) in the bin/Release
folder, and those copies are *not* signed. Slightly worrying.
Anyway, when I build an installer using my Visual Studio 2003 setup project,
things go awry. The installer that gets built seems to contain *unsigned*
versions of the DLLs. (When I use the installer on another machine and look
at the installed DLLs, they're not signed). If I expand the "Detected
Dependencies" list for the setup project and click on one of my .NET DLLs, I
notice that in the Properties window under SourcePath, it lists
..../obj/Release rather than .../bin/Release. That would certainly explain
why it's packing up un-signed versions of the DLLs. (I'm not really sure
what the "obj" folder is all about).
I'm not sure what I should be doing to get around this? Since it's
automatically detecting the dependencies, there's no way for me to tell it
to use the DLL from another folder. And anyway, why is it using this
intermediate folder rather than the output folder for the project? This
seems to make a mockery of the "post-build step" idea.
I could conceivably change my post-build step to work on the "obj" folder
instead, but I'm nervous about doing that since I'm not sure what that
folder is for. Also, it'd be a pain, because the macros in the post-build
event allow me to specify $(TargetPath) etc. but those are all about the bin
folder - there are no equivalents for the obj folder.
Help!
Gary
I have a managed-code shared add-in for Word/Excel/PowerPoint 2003 developed
in VS.NET 2003. I'm using the "shim" solution as described on MSDN. However,
I'm having trouble signing it so that it can be run on a machine with
security set to "very high".
My project consists of a dozen c# .NET DLLs plus the C++ shim DLL. All the
..NET DLLs are strong named.
I reckon that I need to sign all 13 DLLs rather than just the shim, yes? (I
tried signing just the shim, and that didn't work).
To sign all the other DLLs, I added a post-build step that does the signing.
So far, so good. When I build my project, all of the DLLs are signed. To be
explicit: in the C++ project, the DLL in the Release folder is signed; in
all 12 of the .NET projects, the DLL in bin/Release folder is signed.
However, I notice that for those .NET projects that have references to other
..NET projects, there's a copy of the referenced DLL(s) in the bin/Release
folder, and those copies are *not* signed. Slightly worrying.
Anyway, when I build an installer using my Visual Studio 2003 setup project,
things go awry. The installer that gets built seems to contain *unsigned*
versions of the DLLs. (When I use the installer on another machine and look
at the installed DLLs, they're not signed). If I expand the "Detected
Dependencies" list for the setup project and click on one of my .NET DLLs, I
notice that in the Properties window under SourcePath, it lists
..../obj/Release rather than .../bin/Release. That would certainly explain
why it's packing up un-signed versions of the DLLs. (I'm not really sure
what the "obj" folder is all about).
I'm not sure what I should be doing to get around this? Since it's
automatically detecting the dependencies, there's no way for me to tell it
to use the DLL from another folder. And anyway, why is it using this
intermediate folder rather than the output folder for the project? This
seems to make a mockery of the "post-build step" idea.
I could conceivably change my post-build step to work on the "obj" folder
instead, but I'm nervous about doing that since I'm not sure what that
folder is for. Also, it'd be a pain, because the macros in the post-build
event allow me to specify $(TargetPath) etc. but those are all about the bin
folder - there are no equivalents for the obj folder.
Help!
Gary