|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Strong Naming an Assembly using the Project settings in VS2005You get warnings when compiling a project that is using the AssemblyKeyFile
attribute. It recommends changing this to use the compiler option. I read about this and the reasons sound good, HOWEVER signing using project settings require that the snk file exists in the project directory. In fact, if it doesn't and you browse to the file through the UI it copies it to the local directory and adds it to your project. Is there a reason this won't take the key file from a relative path? I do not want to have to have the key file in every project I create. It would be better if the key file was in one place and all projects just referred to the same key file in a common top level directory. Thanks. If you add the snk file to your project as a linked file, you should be able
to specify the relative path without a local copy being made. (See the "Adding an Existing Item as a Link" section at http://msdn2.microsoft.com/en-us/library/9f4t9t92 if you're not sure how to add a linked file to a project.) Show quote "Oldman" <Old***@discussions.microsoft.com> wrote in message news:A26014BE-2E49-45FE-8DAB-A9B5A2204361@microsoft.com... > You get warnings when compiling a project that is using the > AssemblyKeyFile > attribute. It recommends changing this to use the compiler option. > I read about this and the reasons sound good, HOWEVER signing using > project > settings require that the snk file exists in the project directory. In > fact, > if it doesn't and you browse to the file through the UI it copies it to > the > local directory and adds it to your project. > > Is there a reason this won't take the key file from a relative path? I do > not want to have to have the key file in every project I create. It would > be > better if the key file was in one place and all projects just referred to > the > same key file in a common top level directory. > > Thanks. Thanks for your response Nicole!
I tried that but it still looks for the file in the local directory. It doesn't seem to honor a link. Show quote "Nicole Calinoiu" wrote: > If you add the snk file to your project as a linked file, you should be able > to specify the relative path without a local copy being made. (See the > "Adding an Existing Item as a Link" section at > http://msdn2.microsoft.com/en-us/library/9f4t9t92 if you're not sure how to > add a linked file to a project.) > > > > "Oldman" <Old***@discussions.microsoft.com> wrote in message > news:A26014BE-2E49-45FE-8DAB-A9B5A2204361@microsoft.com... > > You get warnings when compiling a project that is using the > > AssemblyKeyFile > > attribute. It recommends changing this to use the compiler option. > > I read about this and the reasons sound good, HOWEVER signing using > > project > > settings require that the snk file exists in the project directory. In > > fact, > > if it doesn't and you browse to the file through the UI it copies it to > > the > > local directory and adds it to your project. > > > > Is there a reason this won't take the key file from a relative path? I do > > not want to have to have the key file in every project I create. It would > > be > > better if the key file was in one place and all projects just referred to > > the > > same key file in a common top level directory. > > > > Thanks. > > > It works for me in the August CTP, but I don't recall if I tried using
linked key files in earlier releases, so the problem might lie with the release that you're using. However, just in case it has something to do with how you're trying to specify the key, you might want to try these steps: 1. Remove all strong naming key attributes from the project code. 2. On the "Signing" tab of the project properties window, specify that the assembly should not be signed. 3. Remove any existing linked key files from the project. 4. Save the project/solution. 5. Add your desired key file to your project as a linked file. 6. On the "Signing" tab of the project properties window, specify that the assembly should be signed and select the linked key file from the list (the target file path will probably be displayed in the list even though the file is linked). 7. Save and compile the project. Show quote "Oldman" <Old***@discussions.microsoft.com> wrote in message news:E317D345-099C-404A-A171-BE9C74212B70@microsoft.com... > Thanks for your response Nicole! > I tried that but it still looks for the file in the local directory. It > doesn't seem to honor a link. > > "Nicole Calinoiu" wrote: > >> If you add the snk file to your project as a linked file, you should be >> able >> to specify the relative path without a local copy being made. (See the >> "Adding an Existing Item as a Link" section at >> http://msdn2.microsoft.com/en-us/library/9f4t9t92 if you're not sure how >> to >> add a linked file to a project.) >> >> >> >> "Oldman" <Old***@discussions.microsoft.com> wrote in message >> news:A26014BE-2E49-45FE-8DAB-A9B5A2204361@microsoft.com... >> > You get warnings when compiling a project that is using the >> > AssemblyKeyFile >> > attribute. It recommends changing this to use the compiler option. >> > I read about this and the reasons sound good, HOWEVER signing using >> > project >> > settings require that the snk file exists in the project directory. In >> > fact, >> > if it doesn't and you browse to the file through the UI it copies it to >> > the >> > local directory and adds it to your project. >> > >> > Is there a reason this won't take the key file from a relative path? I >> > do >> > not want to have to have the key file in every project I create. It >> > would >> > be >> > better if the key file was in one place and all projects just referred >> > to >> > the >> > same key file in a common top level directory. >> > >> > Thanks. >> >> >> Thank you Nicole. I figured out why it didn't work the first time.
The keys were stored in a file with a .keys extension instead of the .snk extension. If I change the file to have the snk extension, everything works as expected. Thanks again, Chris Show quote "Nicole Calinoiu" wrote: > It works for me in the August CTP, but I don't recall if I tried using > linked key files in earlier releases, so the problem might lie with the > release that you're using. However, just in case it has something to do > with how you're trying to specify the key, you might want to try these > steps: > > 1. Remove all strong naming key attributes from the project code. > 2. On the "Signing" tab of the project properties window, specify that the > assembly should not be signed. > 3. Remove any existing linked key files from the project. > 4. Save the project/solution. > 5. Add your desired key file to your project as a linked file. > 6. On the "Signing" tab of the project properties window, specify that the > assembly should be signed and select the linked key file from the list (the > target file path will probably be displayed in the list even though the file > is linked). > 7. Save and compile the project. > > > > "Oldman" <Old***@discussions.microsoft.com> wrote in message > news:E317D345-099C-404A-A171-BE9C74212B70@microsoft.com... > > Thanks for your response Nicole! > > I tried that but it still looks for the file in the local directory. It > > doesn't seem to honor a link. > > > > "Nicole Calinoiu" wrote: > > > >> If you add the snk file to your project as a linked file, you should be > >> able > >> to specify the relative path without a local copy being made. (See the > >> "Adding an Existing Item as a Link" section at > >> http://msdn2.microsoft.com/en-us/library/9f4t9t92 if you're not sure how > >> to > >> add a linked file to a project.) > >> > >> > >> > >> "Oldman" <Old***@discussions.microsoft.com> wrote in message > >> news:A26014BE-2E49-45FE-8DAB-A9B5A2204361@microsoft.com... > >> > You get warnings when compiling a project that is using the > >> > AssemblyKeyFile > >> > attribute. It recommends changing this to use the compiler option. > >> > I read about this and the reasons sound good, HOWEVER signing using > >> > project > >> > settings require that the snk file exists in the project directory. In > >> > fact, > >> > if it doesn't and you browse to the file through the UI it copies it to > >> > the > >> > local directory and adds it to your project. > >> > > >> > Is there a reason this won't take the key file from a relative path? I > >> > do > >> > not want to have to have the key file in every project I create. It > >> > would > >> > be > >> > better if the key file was in one place and all projects just referred > >> > to > >> > the > >> > same key file in a common top level directory. > >> > > >> > Thanks. > >> > >> > >> > > > You want to sign a bunch of different assemblies with the same key? That
kinda goes around the notion of a strongly-named assembly, as the unique ID is now shared among assemblies, and if any assembly had the filename changed to that of one also signed with this key, then the runtime would consider both assemblies to be the same. "Keith Patrick" <richard_keith_patr***@hotmail.com> wrote in message No, it won't. The signature is just one of several elements that form an news:OkwjH%23pzFHA.2072@TK2MSFTNGP14.phx.gbl... > You want to sign a bunch of different assemblies with the same key? That > kinda goes around the notion of a strongly-named assembly, as the unique > ID is now shared among assemblies, and if any assembly had the filename > changed to that of one also signed with this key, then the runtime would > consider both assemblies to be the same. assembly's strong name. (The others are the assembly text name, version, and culture.) There is nothing at all unusual about signing multiple assemblies with a single strong naming key. In fact, in a small development shop, all assemblies might typically be signed with the same key. Larger groups may prefer to use separate keys for separate product lines (for example, Microsoft uses a different key for SQL Server assemblies than it does for .NET Framework assemblies). However, signing each and every assembly with a different key is essentially a pack of hassle with little real benefit. Is there an MS doc that discusses best practices on this? Granted, you are
probably going to have a unique name within your company using a single SNK, with shared ones, it becomes that much easier to have a name collision. Let's say two teams share a common key file among products. If each had a DLL within their product named "Common.dll", what happens if they aren't careful and share the same key file among the two DLLs? They are different DLLs in functionality and code branch, but because their canonical name is the same, and because culture and version can also collide, the one truly unique differentiator is contaminated, meaning those two files could get mixed up but the runtime wouldn't know better. Even if the key is kept in the same product family, who is to say that filenames won't change in the future? I personally would just rather grant each assembly a key file (it's a couple of clicks in the Properties tab) and not worry about cross-contamination. Show quote "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message news:OIVpJwyzFHA.268@TK2MSFTNGP09.phx.gbl... > "Keith Patrick" <richard_keith_patr***@hotmail.com> wrote in message > news:OkwjH%23pzFHA.2072@TK2MSFTNGP14.phx.gbl... >> You want to sign a bunch of different assemblies with the same key? That >> kinda goes around the notion of a strongly-named assembly, as the unique >> ID is now shared among assemblies, and if any assembly had the filename >> changed to that of one also signed with this key, then the runtime would >> consider both assemblies to be the same. > > No, it won't. The signature is just one of several elements that form an > assembly's strong name. (The others are the assembly text name, version, > and culture.) There is nothing at all unusual about signing multiple > assemblies with a single strong naming key. In fact, in a small > development shop, all assemblies might typically be signed with the same > key. Larger groups may prefer to use separate keys for separate product > lines (for example, Microsoft uses a different key for SQL Server > assemblies than it does for .NET Framework assemblies). However, signing > each and every assembly with a different key is essentially a pack of > hassle with little real benefit. > Keith Patrick wrote:
> I personally would just rather grant each assembly a key file (it's a couple I disagree here. A company should only use a single key, or maybe a key > of clicks in the Properties tab) and not worry about cross-contamination. for each development department. If you're using best practice naming your assemblies, they'll never share the same name. It'll be something like "<CompanyName>.<Technology>.<WhatEver>". It is much easier to administrate the delay signing of assemblies before release, and it'll make it possible to use the StrongNameIdentityPermissionAttribute in a usefull way. If you know the company always uses the same key, it's easier to administrate the grant of full trust to a single companys assemblies. /B.signing :) "Keith Patrick" <richard_keith_patr***@hotmail.com> wrote in message I've never seen one.news:ufACbNQ0FHA.2792@tk2msftngp13.phx.gbl... > Is there an MS doc that discusses best practices on this? > Granted, you are probably going to have a unique name within your company This is one possible rationale for assigning different keys to different > using a single SNK, with shared ones, it becomes that much easier to have > a name collision. Let's say two teams share a common key file among > products. If each had a DLL within their product named "Common.dll", what > happens if they aren't careful and share the same key file among the two > DLLs? teams. However, it's also a scenario that is easily addressed by setting up assembly naming policies. > They are different DLLs in functionality and code branch, but because The main problem there lies in management of the private keys. With a key > their canonical name is the same, and because culture and version can also > collide, the one truly unique differentiator is contaminated, meaning > those two files could get mixed up but the runtime wouldn't know better. > Even if the key is kept in the same product family, who is to say that > filenames won't change in the future? > I personally would just rather grant each assembly a key file (it's a > couple of clicks in the Properties tab) and not worry about > cross-contamination. per assembly, how would you protect these? How would you even know if one has slipped outside your key management process? Show quote > > > "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message > news:OIVpJwyzFHA.268@TK2MSFTNGP09.phx.gbl... >> "Keith Patrick" <richard_keith_patr***@hotmail.com> wrote in message >> news:OkwjH%23pzFHA.2072@TK2MSFTNGP14.phx.gbl... >>> You want to sign a bunch of different assemblies with the same key? >>> That kinda goes around the notion of a strongly-named assembly, as the >>> unique ID is now shared among assemblies, and if any assembly had the >>> filename changed to that of one also signed with this key, then the >>> runtime would consider both assemblies to be the same. >> >> No, it won't. The signature is just one of several elements that form an >> assembly's strong name. (The others are the assembly text name, version, >> and culture.) There is nothing at all unusual about signing multiple >> assemblies with a single strong naming key. In fact, in a small >> development shop, all assemblies might typically be signed with the same >> key. Larger groups may prefer to use separate keys for separate product >> lines (for example, Microsoft uses a different key for SQL Server >> assemblies than it does for .NET Framework assemblies). However, signing >> each and every assembly with a different key is essentially a pack of >> hassle with little real benefit. >> > >  |
|||||||||||||||||||||||
Other interesting topics