Lets see Heath answer this one then!
-
The Problem: I'm running C# and VB.NET projects from sourcesafe, with four developers working on the projects at any given time. The majority of any file references such as .DLLs and .SNK files are done via relative file paths i.e. ..\..\DataAccessLayer.snk. In some cases, this relative approach doesn't work for some PCs that the developers use. Instead they need to use: \VMR\DAL\DataAccessLayer.snk OK, you still with me? Good good. Now here's the final straw. We now have a project where neither of these file paths are allowing the project to compile. Instead it needs an explicit path name including the drive letter:
Assembly: AssemblyKeyFile("E:\VMR\DAL\DataAccessLayer.snk")Unfortunately, I cannot impose that every developer keeps their source code on the same drive letter on their machines. The projects must support being installed onto various drive letters. Firstly I cannot understand why a file path will work correctly on one machine and not another - and I have ensured that all the files etc. are in place as they should be. So, unless there's some dumb user option I'm missing here, does anyone know why .NET behaves differently like this? Can I make it work 100% of the time without specifying a drive letter? -
The Problem: I'm running C# and VB.NET projects from sourcesafe, with four developers working on the projects at any given time. The majority of any file references such as .DLLs and .SNK files are done via relative file paths i.e. ..\..\DataAccessLayer.snk. In some cases, this relative approach doesn't work for some PCs that the developers use. Instead they need to use: \VMR\DAL\DataAccessLayer.snk OK, you still with me? Good good. Now here's the final straw. We now have a project where neither of these file paths are allowing the project to compile. Instead it needs an explicit path name including the drive letter:
Assembly: AssemblyKeyFile("E:\VMR\DAL\DataAccessLayer.snk")Unfortunately, I cannot impose that every developer keeps their source code on the same drive letter on their machines. The projects must support being installed onto various drive letters. Firstly I cannot understand why a file path will work correctly on one machine and not another - and I have ensured that all the files etc. are in place as they should be. So, unless there's some dumb user option I'm missing here, does anyone know why .NET behaves differently like this? Can I make it work 100% of the time without specifying a drive letter?Martin Cross wrote: So, unless there's some dumb user option I'm missing here, does anyone know why .NET behaves differently like this? Can I make it work 100% of the time without specifying a drive letter? Just a thought, but why not always map to the UNC path (this way it's the same for every developer), who cares what drive letter any of your developers map to a network share, that could always change per developer as you are noting. In this case, there is even an article on CP to help with UNC paths: Network Shares and UNC paths[^]. P.S. - I'm sure Heath will respond to this eventually, I give him an hour or two. ;)
-Nick Parker DeveloperNotes.com
-
Martin Cross wrote: So, unless there's some dumb user option I'm missing here, does anyone know why .NET behaves differently like this? Can I make it work 100% of the time without specifying a drive letter? Just a thought, but why not always map to the UNC path (this way it's the same for every developer), who cares what drive letter any of your developers map to a network share, that could always change per developer as you are noting. In this case, there is even an article on CP to help with UNC paths: Network Shares and UNC paths[^]. P.S. - I'm sure Heath will respond to this eventually, I give him an hour or two. ;)
-Nick Parker DeveloperNotes.com
Network shares aren't the solution. A lot of us grab the latest version onto laptops and work from home using disconnected checkouts (dangerous I know). So, am I not the only one where the file paths are a bit iffy then?
-
The Problem: I'm running C# and VB.NET projects from sourcesafe, with four developers working on the projects at any given time. The majority of any file references such as .DLLs and .SNK files are done via relative file paths i.e. ..\..\DataAccessLayer.snk. In some cases, this relative approach doesn't work for some PCs that the developers use. Instead they need to use: \VMR\DAL\DataAccessLayer.snk OK, you still with me? Good good. Now here's the final straw. We now have a project where neither of these file paths are allowing the project to compile. Instead it needs an explicit path name including the drive letter:
Assembly: AssemblyKeyFile("E:\VMR\DAL\DataAccessLayer.snk")Unfortunately, I cannot impose that every developer keeps their source code on the same drive letter on their machines. The projects must support being installed onto various drive letters. Firstly I cannot understand why a file path will work correctly on one machine and not another - and I have ensured that all the files etc. are in place as they should be. So, unless there's some dumb user option I'm missing here, does anyone know why .NET behaves differently like this? Can I make it work 100% of the time without specifying a drive letter?Simple: don't use files. Instead of using the
AssemblyKeyFileAttributeuse theAssemblyKeyNameAttribute. Import the key pair into a key container usingsn -i KeyFile.snk MyCompanyand then specify "MyCompany" (or whatever, so long as it matches) as the sole parameter to the latter attribute's constructor. You only need to do this once. The only thing that isn't documented is whether the key container must exist as a machine container or a user container. It probably doesn't matter, but just a heads-up. For a brief description, see my article: Using XML Digital Signatures for Application Licensing[^]. The articles not about your problem, but the solution is discussed a little (about key containers, that is).-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
-
Simple: don't use files. Instead of using the
AssemblyKeyFileAttributeuse theAssemblyKeyNameAttribute. Import the key pair into a key container usingsn -i KeyFile.snk MyCompanyand then specify "MyCompany" (or whatever, so long as it matches) as the sole parameter to the latter attribute's constructor. You only need to do this once. The only thing that isn't documented is whether the key container must exist as a machine container or a user container. It probably doesn't matter, but just a heads-up. For a brief description, see my article: Using XML Digital Signatures for Application Licensing[^]. The articles not about your problem, but the solution is discussed a little (about key containers, that is).-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
Good grief man! That's beautiful. :-o Thanks < bows down as he backs away slowly >