Had a thread with some VS folks… now working on a little prototype for a new CheckUid/UpdateUid to be a bit smarter. Last bit to get working is the actual updating…
From: VS Guy
Sent: Friday, August 07, 2009 5:44 PM
Subject: RE: Uid clashes
I think the logic should be reversed: which elements DO need Uids for localization?
There are probably too many to exclude, but here is a list for start:
- ResourceDictionary,
- Triggers, DataTrigger, MultiTrigger, MultiDataTrigger
- Setters, Conditions,
- ControlTemplate, Style,
- ContentPresenter, ItemPresenter
- RowDefinition, ColumnDefinition
- Rectangle, DrawingBrush, Border, Path, *Geometry , *Transform,
Stop adding UIDs to these and you’ve probably eliminated 90% of the noise for us…
Thanks,
VS Guy
From: Rob Relyea
Sent: Thursday, August 06, 2009 11:59 AM
Subject: RE: Uid clashes - improvements to UpdateUid
No new news on this front since my April 2008 email from your attached thread.
From: Rob Relyea
Sent: Saturday, April 19, 2008 7:54 AM
Subject: RE: Xaml & localization
We will make CheckUid and UpdateUid smarter over time if you think there is a large benefit we can achieve. Today, they are written on top of System.Xml, so it is difficult for them to add smarts. We will likely enhance them to work on System.Xaml.dll in the .NET4 or later timeframe and will be able to more easily optimize them to only add UIDs on some types, etc…
Please give feedback to us on ways you would like to see the Uid addition logic changed…
Thx, Rob
We don’t have short term plans to improve UpdateUid, however, given that we have System.Xaml.dll, it wouldn’t be hard to do…it may even make a good sample.
VS folks-
What elements should we stop writing Uids on, ideally?
Thx, Rob
From: VS Guy
Sent: Thursday, August 06, 2009 11:50 AM
Subject: RE: Uid clashes
We had this discussion ages ago, and we were told pretty much to go with the bloat, same way Cider and Expression did
As for stopping using UpdateUid, as soon as I enabled it, the next day there was a checkin that added a localizable field and forgot the Uid. We caught it because it caused a build break, so the checks are not useless. The question is whether the added value is greater than the pain of running the tool…
It looks like we should send some feedback to them to get this Uid addition logic changed…
Rob, are you aware of any upcoming changes that improve how UpdateUid adds uids to elements?
Thanks,
VS Guy
From: VS Guy 2
Sent: Wednesday, August 05, 2009 9:45 PM
Subject: RE: Uid clashes
(Plus it bloats the size of the resulting XAML and adds to BAML parsing time.)
From: VS Guy 3
Sent: Wednesday, August 05, 2009 9:15 PM
Subject: RE: Uid clashes
I have said this from the beginning, but VS Guy says the loc people claim we have to do it. I think the tool is stupid and puts UID’s everywhere making the XAML MUCH harder to read (who needs to do that anyway…ohh yeah, us) and obscures what needs to be localized from what doesn’t. We definitely should figure out if there is any alternative here.
VS Guy 3
From: VS Guy 4
Sent: Wednesday, August 05, 2009 7:37 PM
Subject: RE: Uid clashes
Or we could stop using UpdateUid to litter the code with x:Uid’s. I really think this is overkill since so little of the XAML has text that needs to be localized.
The Start Page styles and loose xaml files are excluded from the CheckUid build step and we take care to periodically review the code for localizable strings.
From: VS Guy 5
Sent: Wednesday, August 05, 2009 7:29 PM
Subject: x:Uid clashes
On a side note, this problem (I’ve ran into it myself today - almost checked in a dupe Uid) highlights the general problem with our current approach if two people work on the same .xaml file at the same time.
Technically, the proper way to handle this is to do msbuild /t:updateuid immediately before every checkin (and after merge). However, that thing generates Uids in a pretty straightforward manner, incrementing the largest used number. Furthermore, if it finds dupes, it always leaves the first Uid intact and updates the following ones. This isn’t what is always desired. Imagine that we have some XAML like this:
<Setter x:Uid=”Setter_1”/>
<Setter x:Uid=”Setter_2”/>
<Setter x:Uid=”Setter_3”/>
You check that out and start working on it. Meanwhile, someone else checks that out, modifies it, and checks in the updated version:
<Setter x:Uid=”Setter_1”/>
<Setter x:Uid=”Setter_2”/>
<Setter x:Uid=”Setter_3”/>
<Setter x:Uid=”Setter_4”/>
You finish your work, and try to check in your own version:
<Setter x:Uid=”Setter_1”/>
<Setter x:Uid=”Setter_4”/>
<Setter x:Uid=”Setter_2”/>
<Setter x:Uid=”Setter_3”/>
Get a conflict, and merge it as follows:
<Setter x:Uid=”Setter_1”/>
<Setter x:Uid=”Setter_4”/>
<Setter x:Uid=”Setter_2”/>
<Setter x:Uid=”Setter_3”/>
<Setter x:Uid=”Setter_4”/>
If you now run updateuid, you’ll get this:
<Setter x:Uid=”Setter_1”/>
<Setter x:Uid=”Setter_4”/>
<Setter x:Uid=”Setter_2”/>
<Setter x:Uid=”Setter_3”/>
<Setter x:Uid=”Setter_5”/>
So your diff is one line larger than it has to be. For this example it probably doesn’t matter much, but it grows proportionally to the amount of changes, and there are some elements which can be changed in large numbers in a typical checkin (style setters probably being the most notable).
Using some other way to generate Uids (GUID? Epoch time?) would solve this problem, but I don’t know any way to make updateuid use different Uid generation algorithm. Any other ideas? Or is it something not worth bothering about in the end?
---
…