2 comments

  1. Proposed workaround #1 for the keyfile-problem: <br />"Edit the project file with a text editor. Change the path to the shared file, for example ….keys.snk. The build process will work fine, there will not be a local copy made of the file, BUT the VisualStudio GUI shows blank for the filename"<br /><br />Workaround #2:<br />[1] Right click on the root folder of the project and select "Add Existing Item"<br />[2] Browse to the .snk file in the Open File dialog<br />[3] Click on the down-arrow on the button that says "Add" and choose "Add Link"<br /><br />However, I still think it’s lame to state "It’s a lot easier to manage your SCC state, etc. if everything in the project is under a project cone". What’s wrong with making it the programmers responsibility to make sure the keyfile or other files referenced by the project (but outside the projects’ folder) are stored in the source repository?

    robert.te.kaat@gmail.com (Robert te Kaat)

  2. My proposed solution for the keyfile problem is, don’t use it!

    Instead use the AssemblyKeyName attribute. With sn.exe you can register the keyfile on every developer box under a "name". Then in the AssemblyKeyName attribute you can refer to this common name. So every developer can decide by himself where the file is stored (only once!).

    Dennis Mulder

Comments are closed.