tag:blogger.com,1999:blog-2441850399540300710.post8055740185285407808..comments2024-02-17T03:47:06.818-08:00Comments on CraigBlog: I Hate Strong NamesCraig Anderahttp://www.blogger.com/profile/17084199593129216563noreply@blogger.comBlogger36125tag:blogger.com,1999:blog-2441850399540300710.post-21527170505338662572005-05-19T07:07:00.000-07:002005-05-19T07:07:00.000-07:00Right. I think we do agree: your method is a more ...Right. I think we do agree: your method is a more convenient way of doing what I did with a binding redirect. <br /><br><br /><br>So given that *unsigned* assemblies already exhibit the behavior you like, I take it that you (like me) try not to sign unless you absolutely have to? And that you prefer unsigned assemblies?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-18297698744847759222005-05-19T06:55:00.000-07:002005-05-19T06:55:00.000-07:00I think we agree on all points
1. Definitely it&#...I think we agree on all points<br /><br><br /><br>1. Definitely it's about convenience - why should the _default_ behaviour break perfectly good code and require me to edit a config file every time I drop a new copy of a DLL in the folder.<br /><br><br /><br>2. I agree that signing doesn't provide a great deal of security, but my point is that whatever it does provide has nothing to do with versioning.<br /><br><br /><br>I would suggest - versioning is there to support multiple, shared versions in the GAC, once you are deploying to the local folder there are no versioning requirements - certainly not until the OS prevents me from overwriting a file in the local folder (based on version).<br /><br><br /><br>Go back to your original post - my solution would solve the problem 100%, without any drawbacks.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-54120178962116527382005-05-19T05:17:00.000-07:002005-05-19T05:17:00.000-07:00As it stands right now, you *can* control what you...As it stands right now, you *can* control what your application loads. Just deploy locally under a different version number and use a binding redirect in your exe's config file. Is there some value over that to what you suggest? Or is it just slightly more convenient? <br /><br><br /><br>As for signing providing "security", I don't buy it. If they can tamper with a DLL in your app directory, they can tamper with the EXE, and you're screwed. The tamper detection aspects of strong names are almost completely worthlesss IMO.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-44251721589742609822005-05-19T05:05:00.000-07:002005-05-19T05:05:00.000-07:00But surely that's the point - if I deploy priv...But surely that's the point - if I deploy privately why don't I get to decide what "compatible" means in all cases, strong name or no strong name.<br /><br><br /><br>I'm not arguing against the GAC or strong names, but when the assembly is not in the GAC then surely the rules can change. Security is taken care of by the key signing, versions should have nothing to do with security. <br /><br><br /><br>The argument that you shouldn't have 30 copies of an assembly on a machine is another issue entirely. But given that strong named assemblies are allowed outside of the GAC - versioning needs to work differently because the versioning requirements outside of the GAC are different.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-25265683444400595052005-05-18T13:55:00.000-07:002005-05-18T13:55:00.000-07:00The counterargument is a security-based one: if th...The counterargument is a security-based one: if there are 30 copies of an assembly on a machine, and it turns out there's a bug, the GAC is the place where you go to update all of them and eliminate the vulnerability. <br /><br><br /><br>Of course, if you deploy privately with no strong name, you get to decide what "compatible" means. :)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-16603600241139825012005-05-18T10:44:00.000-07:002005-05-18T10:44:00.000-07:00It seems to me that one fairly small change could ...It seems to me that one fairly small change could make all this a lot easier.<br /><br><br /><br>How about if the version number was not checked for strong-named assemblies that are not in the GAC?<br /><br><br /><br>If the assembly is not in the GAC, but only in the local folder, surely the better assumption would be that we _do_ want to use it. <br /><br><br /><br>Lets consider - if the wrong version is in the local folder there are two possibilities:<br /><br>1. It is compatible and everything works.<br /><br>2. It is not compatible and something breaks.<br /><br><br /><br>But - by causing a load error if the version is different, you reduce that down to:<br /><br>1. Whether it is compatible or not, everything breaks.<br /><br><br /><br>This could be controlled by a config option, so that you could turn it off if you don't like it, but it seems it would cause the code to work most of the time with no down-side?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-17615883625355630902005-03-19T01:50:00.000-08:002005-03-19T01:50:00.000-08:00Interesting finds this weekInteresting finds this weekAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-24917528935893254092005-03-16T08:07:00.000-08:002005-03-16T08:07:00.000-08:00Junfeng: thanks.
BTW, the CLR rocks hard overall...Junfeng: thanks. <br /><br><br /><br>BTW, the CLR rocks hard overall. I have to look hard to find things to complain about. Keep up the good work. ;)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-554528756890948112005-03-16T07:03:00.000-08:002005-03-16T07:03:00.000-08:00Wesner,
The work will be done in Orcas.
Jeffrey...Wesner,<br /><br><br /><br>The work will be done in Orcas. <br /><br><br /><br>Jeffrey Richter has an article on the future of assembly versioning<br /><br><br /><br>http://www.theserverside.net/articles/showarticle.tss?id=AssemblyVersioning<br /><br><br /><br>It was the thinking at that time frame. Things will undoubtfully change. But you can have a rough idea on how we will move forward. <br /><br><br /><br>Craig,<br /><br><br /><br>You probably will get what you want. And with more new stuff you may or may not want. It sucks. But that is how we move along. <br /><br><br /><br>The current policy system does have its problem. I constantly hear complain about it. We will work on it. Just not in Whidbey. It is too close to ship.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-79987521056600384382005-03-16T00:24:00.000-08:002005-03-16T00:24:00.000-08:00Thanks Wesner - I'd read your post when you fi...Thanks Wesner - I'd read your post when you first wrote it, but forgot about it until now.<br /><br><br /><br>My thoughts after reading it again are basically, "That sounds even more complicated." and "I'm not sure if that will make it better or worse." <br /><br><br /><br>I'll have to think about it for a while.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-7372367104106381562005-03-15T16:15:00.000-08:002005-03-15T16:15:00.000-08:00See my post in Platform vs Library Versioning (htt...See my post in Platform vs Library Versioning (http://wesnerm.blogs.com/net_undocumented/2004/06/platform_vs_lib.html).<br /><br><br /><br>Jeffrey Richter indicated that config files were not very usable, even for internal Microsoft developers. So, the plan, either for Whidbey or for Orcas/Longhorn (not sure), is that servicing will be the default behavior, without the need to modify a config file.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-9651424205477235782005-03-15T14:11:00.000-08:002005-03-15T14:11:00.000-08:00Versioning policy in .Net has been very confusing ...Versioning policy in .Net has been very confusing to me from the very beginning. One one hand we were told to "put all the assemblies" in the private bin of the app... OK... but now I have component A that relies on v1.0.100.1002 of library A and component B that relies on library A but a newer bug-fixed version: v1.0.101.1050. Not to mention the assembly name clashing, it produced situations that didnt make sense, and could only be solved through the policy binding changes that are difficult to wade through as it is.<br /><br><br /><br>Personally, I will always feel that the framework should honor up to the FIRST 3 numbers, and somehow WARN/LOG when not binding directly to the expected version but finding a newer "bug-fixed" one instead.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-34567377968936390992005-03-15T12:33:00.000-08:002005-03-15T12:33:00.000-08:00Just say no to DLL hell.
How hard can it be to de...Just say no to DLL hell.<br /><br><br /><br>How hard can it be to determine? ;)<br /><br>If you have millions of dollars worth of customer that wants it, then you give it to them.<br /><br><br /><br>I think discussions show that the current solution is not the best.<br /><br><br /><br>Remember this? It confused me: http://weblogs.asp.net/rmclaws/archive/2003/12/23/StrongNameKeys.aspxAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-16759977037436944892005-03-15T10:50:00.000-08:002005-03-15T10:50:00.000-08:00I think Strong Names assemblies are very useful fo...I think Strong Names assemblies are very useful for people who need them; and those people need to develop the appropriate processes.<br /><br><br /><br>General guidance for most developers should 'obviously' be not to use them.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-64422954524323780202005-03-15T00:42:00.000-08:002005-03-15T00:42:00.000-08:00All due respect Junfeng, but when I used to teach ...All due respect Junfeng, but when I used to teach for DevelopMentor, assembly binding and versioning was one of the most topics in the class, and one that students had the hardest time with. Publisher policy in particular. I think *I* understand it well enough, but I got paid to read documentation and explore how it works. That's not really the case for most developers. <br /><br><br /><br>I certainly understand why you made the decision that two different versions are considered incompatible by default. What else could you possibly do? But that doesn't change the fact that versioning sucks, and that for me, it's always been easier to manage versioning independently of what the CLR does for me.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-81391560782928383022005-03-14T10:54:00.000-08:002005-03-14T10:54:00.000-08:00It is not really complicated, it is just inconveni...It is not really complicated, it is just inconvenient. <br /><br><br /><br>Both client and library provider can dictates the version binding policy. Client through app.config and library provider through publisher policy. Actually, this is where the complexity comes in --- too many binding policies. <br /><br><br /><br>We enforce the strict version binding for strongly named assemblies, because, by definition, strongly named assemlies with different version numbers are different. <br /><br>Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-20661498838609626732005-03-14T10:49:00.000-08:002005-03-14T10:49:00.000-08:00Yeah, I think you've hit it right on the head....Yeah, I think you've hit it right on the head.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-84275354863750219422005-03-14T10:39:00.000-08:002005-03-14T10:39:00.000-08:00I think the key issue is that with the current mod...I think the key issue is that with the current model, the library provider implicitly dictates the version binding policy. By choosing to strong name sign or not, the library is controlling whether the client uses "tight" version binding. That just seems wrong to me. The client should determine whether they want to couple to a specific version or not, it shouldn't be dictated to them by the library. <br /><br><br /><br>Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-39514216799641220542005-03-14T10:10:00.000-08:002005-03-14T10:10:00.000-08:00Jenfeng - thanks for stopping by. ;)
IMO, if peo...Jenfeng - thanks for stopping by. ;) <br /><br><br /><br>IMO, if people can understand the way version policy works now, I don't think the variation that Kevin suggests is going to throw them...it's damn complicated already.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-13232878638081827212005-03-14T06:31:00.000-08:002005-03-14T06:31:00.000-08:00@Wesner Moise
The claim is not correct. Whidbey w...@Wesner Moise<br /><br><br /><br>The claim is not correct. Whidbey works the same way as v1.0. The feature you are talking about will happen in Orcas, the release after Whidbey. <br /><br><br /><br>Craig,<br /><br><br /><br>Your observation is well noticed. Yes, if you are component vendor, you have to think about strong name and versioning. <br /><br><br /><br>Kevin,<br /><br><br /><br>That is a good suggestion. I'll keep it in mind. <br /><br><br /><br>It is hard to say if this is a flaw or not. If the binding behavior is different in GAC than in app base, people will be more confused. <br /><br><br /><br>But we will work on this problem. If you have idea, send me email via the contact link on my blog.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-88223068508449311512005-03-13T15:02:00.000-08:002005-03-13T15:02:00.000-08:00Actually, I meant that in a very positive way. I l...Actually, I meant that in a very positive way. I like having to defend my statements from rational objections - that's a great way for me to learn. Don't change a thing.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-39323823916449662812005-03-13T13:52:00.000-08:002005-03-13T13:52:00.000-08:00Dang, I never intended to get the reputation of be...Dang, I never intended to get the reputation of being a PITA. I'm a big fan of your blog, and have learned a lot from it.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-39533766294027445252005-03-13T13:33:00.000-08:002005-03-13T13:33:00.000-08:00Ha ha ha. Yeah, whenever I see a comment from Kevi...Ha ha ha. Yeah, whenever I see a comment from Kevin Dente, I always know my feet are about to be held to the fire. :)<br /><br><br /><br>On the one customer point: conceeded. <br /><br><br /><br>On it not being easy to determine: also agreed.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-10145943779928907282005-03-13T11:51:00.000-08:002005-03-13T11:51:00.000-08:00Perhaps when I said "all it takes is one cust...Perhaps when I said "all it takes is one customer" I should have said "all it takes is one sufficiently important customer". When several million dollars are on the line (as they frequently are in the business in which I work), management may be right to apply that grease, even if it isn't the best technical decision. <br /><br><br /><br>My original point was simply that "unless you need to" isn't necessarily an easy thing to determine, since you are affecting more than just yourself when you make that decision about your library. <br /><br><br /><br>Ultimately, I think it's a flaw in the framework that I hope will be addressed.<br /><br><br /><br>Whew - being in violent agreement with you is exhausting, man. ;)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2441850399540300710.post-78385675521540104622005-03-13T08:14:00.000-08:002005-03-13T08:14:00.000-08:00Make sure you give Rich (http://hoser.lander.ca/) ...Make sure you give Rich (http://hoser.lander.ca/) an earful about this if you get a chance... I'm still trying to convince him that Java's classpath-based loading, while leads to a bit of path hell, is less hellish than our current loading/binding/deployment situation... :)Anonymousnoreply@blogger.com