GlennDoten said:
There's no problem to get around. That's how VS has always worked. I can
see your point about the dialog allowing more options, but it's not
necessary and certainly not broken, IMO.
Clearly I disagree - and as I've shown, I'm not the only one who thinks
this is unintuitive and unhelpful behaviour.
Yes, you know what I mean and you know it takes "zero effort".
In this case? Yes. Because you'd never do this 1000 times. It seems like
you are making up unrealistic hypotheticals for reasons that are beyond
me. I think we all understand that VS didn't work the way *you* wanted
it to w.r.t. key files so therefore it must be VS' fault. If you use the
tool properly it works just fine and takes "no effort". Just like I
would say it takes "no effort" to add an AssemblyInfo.cs file to a
project or something equally as simple and brainless to do. Why do you
want to make this out to be more complicated than it is?
Why do you want to make it out to be *less* complicated than it is?
I've never claimed it's a massive amount of effort - just that it's
non-zero, that using VS the way that *it* recommends does something
which will be wrong for a significant number of people, and that
genuinely doing nothing is easier than doing *something*.
You're right. I shouldn't have said "I can't reproduce that." I missed
cutting that out during my proof-read of my post after showing you how
the attribute is supposed to work. My mistake.
Thanks. That certainly takes a bit of the heat out of the conversation.
It is not an "unfortunate consequence." It is quite by design that the
usage of that attribute within a signed assembly requires you to sign
the friend assembly. And that's the way it should be and is the indeed
the intent. Why do you think a friend assembly should not be signed if
the assembly it is allowed to see the private members for is signed? It
makes complete sense to me and more importantly that is how it is
implemented.
It makes sense to me in the way that assembly references from signed
assemblies work. It's unfortunate in that I really don't want it to
work that way for the use I make of InternalsVisibleTo.
But this is a red-herring you've thrown in and really has nothing to do
with the general precept and good practice of signing any assembly you
create because it is *the easiest thing to do* when creating the most
flexible of assemblies.
It's not easier than not signing it when it doesn't need to be signed.
In cases where I'm *not* using InternalsVisibleTo, why would I want to
sign a unit test assembly?
Um, no you don't have to use that attribute. Clearly you haven't used
Visual Studio's test framework, either.
I use NUnit rather than MSTest because I use VS Professional. I'm
intrigued though - how does MSTest let you access non-public members
from test assemblies?
Um, no. You were talking about assemblies that the production
assemblies use. I was talking about assemblies that the unit test
assembly references. They're not necessarily the same thing. I'm not in
the habit of referencing unit test helper libraries, mocking frameworks
etc from production code.
Yup. If a vendor insists on distributing an assembly without signing it
and you must have it signed this is an absolutely correct observation.
But so what, what's your point?
That it's another point of effort.
It's as free as these things get. Don't try to lead readers of this
thread to think that it's some big god-awful bit of work. It ain't.
You've been trying to give the impression that it's really no effort at
all to sign assemblies, when in reality it *is* effort. Is it very much
effort? No. Is it more effort than not signing assemblies when you
don't need to? Yes - particularly when it means having to rebuild third
party assemblies. (Depending on your view on key storage, you also need
to work out an appropriate security strategy etc. May or may not be an
issue depending on the situation.)
Yes, effort that users of such libraries should not have to expend.
But according to you it's no effort to do anyway, is it? Given that
you're getting the code for free
Jesus! It's not my way of doing things. It's how Visual Studio works.
And it works perfectly. *You* may not like how VS is implemented and
*you* may like to see some changes to VS, but that's *your* problem.
When used properly, the tool (VS) works perfectly well.
1) It doesn't do what I *expect*
2) It doesn't do what I *want*
3) By default (using the method recommended by the compiler, no less)
it tries to add a potentially security-sensitive piece of
information into source control
4) It's not just me that finds this behaviour inappropriate, as I've
shown elsewhere.
Yes, silly me for believing the documentation. Nowhere prior to my
questioning your comment did you say you had actually worked with the
documentation. And once I tested this all out for myself (because you
were clearly showing a lack of understanding on how VS works) I admitted
my mistake. What's the problem there? You, on the other hand, cannot
seem to admit your misunderstanding of VS but being unable to make the
blame stick to me you blame the tool. What's up with that, Jon?
The difference is that I'd already made a claim about a problem with
InternalsVisibleTo which indicated that it didn't behave in accordance
with the documentation. You chose to believe the documentation blindly,
assuming that I was the one in the wrong. If I'm looking at someone's
claim that some code behaves in one way and the documentation says
something else, I try it first.
Now, when it came to signing in VS, I followed what VS suggested: and
it did the wrong thing for me (and the wrong thing for anyone who
didn't want the key copied - which I believe is many people). I then
reported here that it was doing the wrong thing. I fail to see where my
fault lies there.
Yes, clearer documentation on that attribute would be nice. But it
*still* is a red-herring that really has nothing to do with the central
discussion point here.
I disagree, because again it means that more needs to be signed. It
means there's less of a half-way house. If you are going to sign
absolutely everything, I agree that it makes no difference. Can you not
see that some people may agree with you to the extent of wanting to
sign all production assemblies, but *not* extend that to signing test
assemblies and their dependencies?
If you are able to sign your assembly there is absolutely nothing viral
about that. If you are able to sign your assembly you have already
worked out any issues there might be with dependent assemblies. You
described viral as being that users of the assembly you just created
*and signed* is somehow viral and causes users to have to sign their
assemblies. That just ain't so! Users of a signed assembly *do not* have
to sign their assembly. If they did, then it would be so-called viral,
and I would agree with you.
No, here's how I described viral:
"by applying the property to one thing, it's required for others"
The "others" in this case are everything it references, *and* anything
that it wants to give friend access to.
I don't see that it has to be extending to "users" rather than "used"
to count as viral.
Nope, only if you want to sign *your* assembly. Re-read what you just
quoted me as saying: "it sounds like you believe signing an assembly
requires any users of the assembly to sign their assembly as well." It
still sounds like you are trying to say that.
No, I've never said that and wouldn't say that. What I've been saying
(and which you agree with, I believe) is that if I sign assembly X, I
have to make sure that everything X references (*not* everything that
references X) is signed. That may well include assemblies I wouldn't
otherwise have signed - hence the viral nature. "By applying the
property (assembly signing) to one thing (assembly X), it's required
for others (the assemblies X references)." Does that make it clearer?
Users of a signed assembly
do not require that anything you reference in your assembly that uses
the signed assembly must be signed! Why are you arguing that?
I'm not. Please don't put words in my mouth.
If I create an assembly, and sign it and call it AS, and it uses an
assembly called D1, yes, D1 must be signed. But of course it does
otherwise I would never have been able to sign AS. If you create a
unsigned assembly called J and you want to use AS (which is already
signed) and you also want to use assembly ANS which is not signed, *you
can do that!* You're J can use my signed AS at the same time it uses the
unsigned ANS. What are you arguing against here? I am missing something
fundamental in your argument, I think.
You're arguing against something I've never claimed. Hopefully two
paragraphs above will clarify it.
Well go ahead and ignore the *direction* of these dependencies. I don't
know why you are intentionally making this difficult for people to
follow, but you are. Signing is extremely simply, not only conceptually
but in practice as well. Signing requires dependencies that are used by
*signed* assemblies to be signed themselves - it *does not require*
users of a signed assembly to have to sign their assembly if they do not
want to.
And once *again* - I've never said that it does. I don't believe that
makes it any less viral. A good example of this came up just recently
at work: I was trying to test a signed assembly, and I wanted to use
InternalsVisibleTo. That meant I had to sign the test assembly... so I
tried that, but then of course it referenced other assemblies which
weren't signed... which in turn referenced other assemblies which
weren't signed. Rather than follow this chain of signing dependencies,
I ended up making the member public - but the point is that the
"signed-ness" was "trying" to spread itself (with trying in *heavily*
inverted commas, I want to point out).
Now, don't get me wrong: I can see *why* references from signed
assemblies need to be signed. That doesn't make it any simpler when I
don't want to sign those references though - in the same way that I can
understand why deterministic finalization isn't part of .NET, but I
sometimes wish it were.
I've given the benefits a couple of times now and will not reiterate
them again. You are obviously quite free to not sign assemblies that you
create. But that you make this decision for your own assemblies has
absolutely nothing to do with my precept that it is a best practice to
simply sign all assemblies that a person creates. I really don't care
what you want to do with your own assemblies at this point. But if you
would care to debate the pros and cons of what I have been saying and
have maintained all along please do.
Unless you have to sign it for the sake of InternalsVisibleTo, what is
the benefit in signing unit test assemblies? Why is that best practice?
I don't either. And if vendors would sign their assemblies you wouldn't
have to. You're too funny. Just because you say signing an assembly
gives it some sort of viral nature doesn't make it so. I've explained
why but you choose to obfuscate the issue rather than accept the fact
the users of a signed assembly do not have to sign their assemblies to
used the signed one which disproves your claim to virility (is that a
word?)
It doesn't disprove it, it just means that you're asssuming that being
viral only applies in one direction. As far as I'm concerned, if the
property effectively spreads itself (this time via the relationship of
"referred to" rather than "referenced by") when I may not want it to,
then it's viral.
You just keep telling yourself that there is some viral nature
you must cope with; the rest of us will continue to happily sign our
assemblies and be done with it once and for all. Signing them are the
easiest way to create assemblies, for everyone and every tool involved.
If you believe that "the rest of us" are already signing everything,
why have you been having to suggest that people *start* doing so?
There's nothing that needs to be worked around w.r.t. VS. Just admit it.
You didn't know how to link files in VS and that how by doing so the VS
application properties drop-down then automagically finds the key file.
I didn't know that either when I first went from VS'03 to VS'05, but
it's a pretty sharp feature.
I knew about linking files in general - I hadn't tried applying it to
key files. Silly me, I tried doing what the documentation recommended.
I've given plenty of points to recommend. Why don't you address those
points instead of ignore them? Tools like BizTalk require signed
assemblies? How would you recommend people work around that? (Not using
BT is acceptable in my book! It's a beast.) Why don't you address the
point about a user not being able to sign their assembly if some vendor
refuses to simply sign their paid-for asssembly or assemblies? What's
the work-around for that than what I've already said. Jon, I'm afraid
you have lost me in this discussion.
Have I ever suggested not to sign *any* assemblies? No. I've explicitly
said that there are times when it's worth signing assemblies. I've just
been arguing that it:
1) It *isn't* zero effort
2) Following the compiler's recommendations gives broken behaviour for
most users
3) Signing has a viral nature which is understandable but can be
unfortunate
You are entitled to your opinion. I happen to think VS works wonderfully
with key files. What you should be doing is putting one copy of the key
file in the solution directory. Then *link* (as I've described in my
comments you so conveniently snipped away) to the key file in each
project that you add to the solution as you add it to the solution.
And if the compiler had suggested doing that, then it wouldn't have
been a problem. However, I went to the suggested property tab, and it
did the wrong thing - for me and for other people.
I'm glad there's a workaround, and as I've said before I'll use it
(hence the snipping - I've never tried to deny that your workaround
works) - but I still believe the VS property tab's behaviour is badly
designed.
Then go to the signing tab *just once* for each project as you add the
project to the solution. That's how VS is designed to work. You really
do want you key file in the solution so that you can more easily add it
to your source control system.
It's fewer clicks to add a single file to source control than it is to
make an assembly signed - and therefore zero effort in your view,
surely. And this really *can* be a one-off hit; it doesn't even need to
be once per solution - if you want to share a key across multiple
solutions and multiple projects, you don't need to add it to source
control more than once.
That's assuming you *want* to have it in source control, of course - in
some environments you may well not want it in the relatively public
gaze of source control to start with.
I've through all of these configuration issues with VS over and over for
the past seven years at the various multinationals and mom and pop shops
I've held contracts at. *It works!* *I'm not making this up!*
Nor was I making up its broken copying behaviour.
Have you ever tried to deal with BizTalk and vendor assemblies that
aren't signed in a large corporation? If so, what has your-workaround
been when you have to sign an assembly for BizTalk's sake (or for many
other reasons) and you run across an assembly some dopey vendor has
decided not to sign?
I've never used BizTalk, but I would of course sign any assemblies that
I wanted to use with it. And if I were a component vendor, I'd sign
those component assemblies too. I'm not a component vendor, however. I
never expect my assemblies to be used with BizTalk - they're not meant
to be API assemblies in the first place.
Couldn't tell ya. I'd have to see the VS'03 solution and how it was set
up and then see what was done in VS'05.
It was a simple AssemblyKeyFile attribute in AssemblyInfo.cs. The
solution still built and was signed after upgrade, but with an extra
warning. I can't easily reproduce it on my home laptop as I don't have
VS2003 on it, but if you still believe I was doing something wrong I
could try to create a sample solution on my other machine.
Yes, this fellow also does not know how to link files in VS: "When I
referenced this strong name key file, VS2005 copied it into the project."
Yes, again someone followed the recommendation of the compiler. How
terrible of him.
I thought it was common VS knowledge about linking files like the key
file and creating a solution-wide .cs file for the solution-specific
attributes that by default are placed in AssemblyInfo.cs so they can be
shared by all projects. Guess not.
I can't say I've ever created a solution-wide .cs file, although I've
linked other .cs files at other times.
Bully for him! You two need to send a change request to MS, I guess.
I might put a feature request on connect.microsoft.com, I suppose.
Yeah, that's a compiler warning. OK, what's your point?
That it exists. That I'm not making it up.
All the stuff I've pointed out, for a second time now.
Here's what I wrote:
<quote>
Sounds like you'll get a load of warnings in VS2005, which recommends
setting the key file in the project properties rather than
AssemblyInfo...
</quote>
Now, do you believe that it "isn't true" that VS2005 recommends setting
the key file in the project properties rather than AssemblyInfo?
Oh come on. I said I have been signing assemblies since 1999 or 2000. I
never said I've been signing assemblies with VS'05 since then. I've just
kept up with how the different versions of VS work as they've come out.
Signing assemblies since 1999 eh? Before .NET was even *announced* -
very impressive!
Whatever. You keep frightening everyone with this line, the rest of us
will continue to take the five seconds required to add a key file
reference to a project.
I like to streamline development where I can - so if there's no benefit
from signing an assembly in a particular situation (most unit test
projects, for instance) why should I do it?
These word games of yours are tiresome. Can you not argue the point?
Must you continue this game of trying to shift the subject to something
it isn't and is clearly not what I said?
I don't see how you "clearly" meant commercial code when you said
shipping code. Likewise I don't see how you "clearly" meant component
code rather than assemblies which are never meant to be referenced by
other developers.
Oh I see your point. It's better to make untold numbers of people
rebuild your assembly from source than for *one person* (that's you) to
take a *few seconds* to reference a key file in your project.
If anyone ever actually mails me about this, I'll start signing at that
point. Until anyone expresses an interest in having the assembly
signed, I don't see where the benefit is.
See how not singing makes life difficult for your
assembly users? You claimed above that "it's pretty difficult to do so
[sign a non-signed assembly]". You don't think that's putting an
unnecessary burden on the users of your assembly?
Well, for a start that's out of context.
So why not answer the question? You don't think that's putting an
unnecessary burden on the users of your assembly?
My users don't seem to think so, or at least they haven't made any
mention of it. Of course, I've no idea how many users I actually
have...
(No, I didn't quote you out of context, BTW.)
Yes, you did. You included part of a quote which was about signing
assemblies where only the binary was available, and applied it to my
library where the source is available.
Oh but taking a few seconds to sign the thing once to begin with is
"pretty difficult?" I'm now at a loss for words (believe it or not!)
I'm at a loss to see how you are missing the point so badly:
Open source -> Can easily be rebuilt -> Signing makes it a little bit
harder
Only binaries available -> Can't easily be rebuilt (needs
disassembling) -> "pretty difficult"
I don't think I've ever said it was "pretty difficult" to sign the
library to start with - just more effort than not signing it.
You put all your development tools on your production systems? How
bizarre. I make my test and QA and staging systems match production as
much as possible, there's no way development boxes will ever come close
to looking like a production box at the places I've worked. Even the
operating systems are entirely different.
Maybe I should rephrase: "Where I have a choice between two simple
options, one of which makes development and deployment more different,
and one of which keeps them similar, I'll keep them similar."
That includes not using the GAC for my assemblies.
However, the GAC is still useful in many more situations.
I'm glad you find it so - I prefer XCopy deployment for my own
assemblies.
You lost me there: What good is an assembly if no one references it?
Um, being an application? Or being referenced by an application from
the same vendor?
Yes. Sign *any and all* assemblies. It makes life easiest for everyone.
It makes it no easier for applications or unit test assemblies which
don't need access to internals.
You should have read the VS instructions first, I guess.
No, VS should just offer more sensible behaviour in its property pages,
IMO.
Well, if you were doing what the fellow at dougrohm.com that you quoted
was doing then you didn't have your solution configured properly in
VS'03. Sure, it'll let you do that, but I learned back with VS 7.0 (I
think that was the version #) not to keep solution files outside the
solution directory. Doing that also tends to confuse source control systems.
Again, you're assuming that the key file is effectively owned by the
solution. That's a pain if you've got multiple solutions which want to
use the same key. With a relative path in the project file, nothing's
been confused so far - it was just more effort than it would have been
if VS had put that relative path in to start with.
Again, that has nothing to do with my question.
It has everything to do with your claim that it's worth signing
everything. Consider this situation:
1) I have a production assembly. I might choose to sign it - irrelevant
to this example.
2) I have a unit test assembly, which doesn't need access to the
internals of the production assembly.
3) I have a third party assembly referenced by the unit test assembly.
It's not signed.
Now, where is the benefit in signing assembly 2, given that it means
rebuilding (possibly from the binaries - which may be against the
licence) assembly 3?
