Silverlight : How to map multiple namespaces to single FAKE URL

Today's post is on Silverlight. This is very basic but really important one. It's  about how to use fake URL while mapping to multiple namespace across assemblies. I will describe how to create such URL and mapping to our own assemblies & namespaces.

While designing XAML pages in silverlight, we have seen bunch of URL like
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"

These url maps to some assemblies and multiple namespaces, so how & why to do this??

Whenever we import some namespace, we have to give alias like "X" / "mc" / "sdk"/ whatever for each namespace. Let's suppose we have 10 custom namespaces to import then we have to use 10 alias for them and this is why Microsoft implements this Fake URL method to import all namespace with 1 URL.
So, let's see how Microsoft did this magic.

1) Create/open  Silverlight Project to get started.

2) Now, let's add our own custom Control Library to this solution.

3) Remove class1 default file & add New Item -> select Silverlight User Control and give name MyLoginControl

4) Let's add another namespace to this project by adding new Folder "NewControls" & Add another Silverlight User Control.
So, we have 2 namespaces in this project
1) MyControls
2) MyControls.NewControls

5) Let's bind it to fake URL.
Open AssemblyInfo.cs file from Properties folder

Add following lines above assembly definitions:
[assembly: XmlnsDefinitionAttribute("http://durgeshg.blogspot.com", "MyControls")]
[assembly: XmlnsDefinitionAttribute("http://durgeshg.blogspot.com", "MyControls.NewControls")]

now, Compile it.

6) Open Silverlight application project & add reference to our new Custom Control from projects tab.
7) Open MainPage.xaml file & let's import those new control by adding line:
xmlns:dg="http://durgeshg.blogspot.com"
now, use this alias dg. Here it goes, we have all those 2 namespaces mapped.

That's all folks. I hope you like it. Please put your comments & feedback.

Thanks.CodeProject

Best Practices & Guidelines to use TFS CONTINUED...

Branching & merging.

Guidelines continued:

Branching & Merging start.

13. No more than 2 active branches within Release/Iterations.
14. Main always leads towards future release.
15. No Development builds for QA automation, staging, UAT & Production.
16. Always map branch to local folder, do not map Project root or sub-folder inside a branch.
17. Merge always branches, not single file or folder.
18. In forward Merge, Select all changeset.

And the last one which is most important, which should be followed to accomplish all above points:

19. No consolidate check-ins.That's all folks. I hope you like it.
    Plz let me know, if u have any questions & doubts.
    Share your experience & problems.

CodeProject

Best Practices & Guidelines to use TFS

In our everyday development, TFS (Team Foundation Server 2008/2010) has become the important part of our project. We  being developers daily check-in, check out files and perform various operations. We hardly bother about folder structure, check-in with or without comments, etc. Do we really follow any practices ? Not even our TL or PM care about it but it matters when the project becomes huge, big team working on it. One team working on Development, other on Testing or even multiple teams are working on development to accomplish Parallel development (PD) for agile methodology. PD is not a simple task to do and many TL & PM don't prefer it because they don't follow any practices & guidelines to use TFS.

I am sharing few points that I learned and I think they are really helpful to accomplish all development needs for agile.

Basic Guidelines

1. Do not add binary files to Source Control which can be easily created except static dlls.
2. Always create 1 Main branch which shouldn't be used for development.
3. Main should be always stable & clean.
4. No direct check-ins in Main.
5. Use branching & merging.
6. Create branches and divide them as per various release or iterations
7. Merge often, at least once in a day within release.
8. All branches must be originated from Main.
9. All active branches must be in sync.
10. While branching source must be latest.
11. While merging destination must be latest.
12. Don't reuse or delete dead or unused branches
    
    To be continued.....Plz let me know if you have any question & comments. If required I will elaborate required points.
    Thanks.

CodeProject