Doesn't like a particular namespace

Hi,
Can someone try and replicate an error for me. Follow these steps:
1) Create a new package
2) Place a Sequence container in it
3) Create a variable called User::ContainerStartTime scoped to the package
4) Create a variable called User::ContainerStartTime scoped to the sequence container
5) Change the namespaces of the 2 variables from "User" to "Metadata"

You get an error on step 5 saying another object in the collection already has that name yet it doesn't mind them when they're both called User::ContainerStartTime

Why?
-JamieOk, I also got an error following those steps... Weird.
Could it be that the scopes only exists in the user namespace?
|||Yes Jamie, I replicated it as well. I am on Sep CTP. I agree it should complain for User namespace as well as Metadata. Why is Metadata namespace different?|||

Samuel L wrote:

Ok, I also got an error following those steps... Weird.
Could it be that the scopes only exists in the user namespace?

Seems that way. If that's true I'd say its a bug!

-Jamie|||

Sutha Thiru wrote:

Yes Jamie, I replicated it as well. I am on Sep CTP. I agree it should complain for User namespace as well as Metadata. Why is Metadata namespace different?

It actually happens for any user-defined namespace (e.g. change "Metadata" to "Foo") (Confusingly the User namespace isn't a user-defined namespace!!!)

-Jamie|||The problem is that scopes are not part of the qualified name. Whilst the inner variable should override the outer, they are obviously hitting a problem during variable access or enumertion whereby the inner object can still see the outer variables.

At runtime when reading the value, you would only get the value of the inner variable, and there is no way to request the outer, as you can only use the qualfied name, not scope or id, and the name is the same.

I hit the same problem myself during some development, you get more variables than you expect, the scope is different, but the qualified name is the same. By design apparently, although clearly there is a bug in the UI.|||Yep, this is a bug. What's interesting is if you change the order of renaming, it doesn't happen. Looks like there is an order of execution bug.
Change the local scoped variable first and then the outer scoped variable and it won't repro.
Please open a bug.
Thanks,
K|||OK. 209356710|||The bug has been closed apparently cos it can't be reproduced. Which I find strange seeing as 4 people on this thread repro'd it and I have just now repro'd it on RTM.

https://beta.microsoft.com/source/BPBugDetails.asp?TrackID=209356710&ProgID=969000000&FormID=2718&BPW=141044
Apologies for being a bit blunt but what's the point in us raising bugs if they're ignored?|||

Hi Jamie,

Yes, but we had already found and fixed it for SP1 and that is what it is being tested on for repro and closure, since we are no longer testing on RTM. A better resolution would have been no longer repro and comments should have been given as to why it was closed but the problem has been addressed. Thanks for reporting this issue, we appreciate your feedback.

Matt

|||Fair enough Matt. Thanks for the reply!

-Jamie