This project has moved and is read-only. For the latest updates, please go here.

Non namespaced qualified generic cref does not resolve?

Topics: User Forum
Mar 1, 2012 at 6:48 PM

I understand why a <see> to a generic that is not namespace qualified results in a documentation that looks like:

A default implementation of [!:AppSecMembershipProvider{TMembershipProvider}]
But shouldn't the [! indicate to sandcastle that the current namespace should be referenced?  Why doesn't this resolve to a link?
Thank you,

Mar 1, 2012 at 8:31 PM

The "!" prefix on a member ID means that the compiler couldn't resolve the reference.  If that's the case, you should be seeing warnings when you build your assembly.  That could be because it didn't have enough information to resolve it, the ID is misspelled, or that it couldn't import comments from an external source using the <include> element.  As such, you can't just assume that it's missing a namespace and will be found within the current namespace.  If valid and the compiler couldn't resolve it, it most likely appears in a different namespace.

If you aren't getting a compiler warning, it's probably okay in the XML comments file.  You can verify this by looking in the XML comments file for the affected member comments to see that it is valid and fully qualified in there.  The compiler will fully qualify the name when it writes it out.  If it won't resolve when you build the documentation, then it's not being found because it's missing from the reflection data for some reason.  This can happen if you have comments on a public member with a reference to a private type that isn't documented.



Mar 1, 2012 at 8:50 PM
Edited Mar 1, 2012 at 8:51 PM

Slightly embarassed here.  I was using C# syntax in the reference URI rather than VB.    It's going to be years before we're fully C# unfortunately and context switching errors are probably going to be an issue.  On a positive note, at least I know now to pay attention to the warnings.

Sorry for the distraction.