Error: The default XML namespace of the project must be the MSBuild XML namespace

One day you get to work, your boss tells you that there is a project that he needs you to work on, you get the code from source control and open the project up in Visual Studio.NET

During project loading you get a series of crazy errors you have never seen before, ultimately ending in:

error : Unable to read the project file '.csproj'. .csproj(2,1): The default XML namespace of the project must be the MSBuild XML namespace. If the project is authored in the MSBuild 2003 format, please add xmlns="http://schemas.microsoft.com/developer/msbuild/2003" to the element. If the project has been authored in the old 1.0 or 1.2 format, please convert it to MSBuild 2003 format.

You scratch your head, with a big thought cloud overhead that reads “WTF???”

LoadError

You notice that the Silverlight project (in my case the project’s called “SilverlightInterface”) failed to load and is “unavailable” in Solution Explorer:

unavailable

So you try to “reload” it by right clicking on the (currently unavailable) project and selecting “Reload Project” from the menu, only to get an even nastier error message:

MSBuildError

Looking at the Output Window you’re faced with a never-before-seen error which states something about the The default XML namespace of the project must be the MSBuild XML namespace.

Fortunately the solution is simple:

  1. In Windows Explorer navigate to the project
  2. Right Click on the .cproj file, select Properties, and un-check the “Read Only” checkbox
  3. Open up the .cproj file in Notepad
  4. On line 2 change xmlns=”http://schemas.microsoft.com/developer/msbuild/2008″ to xmlns=”http://schemas.microsoft.com/developer/msbuild/2003″ (notice this only difference is we changed 2008 to 2003)
  5. Save your changes
  6. In Visual Studio right click on the (currently unavailable) project and select “Reload Project”
  7. The project will now load normally and you can get on with your life

Error: Could not load file or assembly System.Windows.Interactivity

Silverlight 4 and Visual Studio.NET 2010 are awesome, however if you are required to create a Silverlight 3 application and currently are using Visual Studio.NET 2010 than the default target for your Silverlight app will be version 4. You will have to go into the Properties panel for the Silverlight app and change its target to point to SL 3.

Symptoms:

While this is usually not an issue occasionally you may run into a deceiving error message. The project builds fine, you check the reference to the System.Windows.Interactivity assembly and it does exist, however when you go to view the XAML in the designer (either in VS or in Blend) you get the following error:

 


system-interactivity-error

Cause:

This is caused when your SL 3 app references any assembly that targets a newer version, for example Microsoft.Expression.Prototyping.Interactivity.dll or Microsoft.Expression.Interactions.dll that are found in Blend 4.

 

Resolution:

Removing the references to these assemblies will resolve the issue.

 

Error: This assembly may have been downloaded from the Web

If you’re like most programmers you get a LOT of stuff from the Internet, like sample projects, assembly’s (i.e. .DLL’s), etc… It seems like just about everything we do these days in software is somehow related to the Web, even if that means you are just blogging about it.

After upgrading a Silverlight project so that it can be developed on Visual Studio.NET 2010 I ran into a show-stopper error:

Could not load the assembly file:///.... .dll. This assembly may have been downloaded from the Web. If an assembly has been downloaded from the Web, it is flagged by Windows as being a Web file, even if it resides on the local computer. This may prevent it from being used in your project. You can change this designation by changing the file properties. Only unblock assemblies that you trust. See http://go.microsoft.com/fwlink/?LinkId=179545 for more information.

 

The recommended solution is to “Unblock” the content through Windows Explorer, the only problem is that I was developing this application on a machine at my work and that machine’s Security Settings prevented the “Unblock” feature from Windows Explorer (you couldn’t even see the Unblock button), I thought I was totally screwed.

frustration After banging my head on the desk a few thousand times a co-worker finally suggested that I copy the DLL’s to a Fat32 drive (like an external Thumb drive), then copy them back to the orginal location (over-writing the originals with the copy).

I then simply needed to select “View All Files” for the project in Visual Studio, expand the Bin directory, and delete all the contents (I also removed the reference to the DLL and re-added it just to be safe).

Recompiling the project was successful and I could finally get back to work, what a pain in the a—, hope this helps you fix this issue if you run into it

Silverlight Straight Talk: The Awesomeness, Disadvantages, and Difficulties in Silverlight

Building Silverlight application takes time, effort, patients, and tools (yes, you have to have some tools). In this post we will cover: where to get the necessities and some useful additional tools, as well as straight talk about the awesomeness, disadvantages, and difficulties of building Silverlight applications.  We will also cover the basics of XAML, referencing and using related assemblies, and the how Expression Blend and Visual Studio make it all happen.

filetypeicon_PDF

PowerPoint-Icon

Where to Get the Necessities

http://silverlight.net/GetStarted/

Must Have tools

  • Visual Studio.NET 2008 or 2010 (available from the link above)
  • Expression Blend 3 (available from the link above)
  • Silverlight Spy
  • Fiddler Debugging Tool
  • FireFox with FireBug(Tools àAdd-ons àGet Add-ons)

Useful Additions

Straight Talk: the Awesomeness, Disadvantages, and Difficulties in Silverlight

  1. You, as a developer, now can and should learn how to developer professional grade User Interfaces that offer end users an engaging and user friendly experience. You will take on both the role of Designer and Developer.
  2. The things that you wished you could do in C# instead of JavaScript can now be done, this frees you from the limitations of the typical web application.
  3. The learning curve: its steep (but not mount Everest)
  4. XAML, it’s a whole new world.
    • Its an unfamiliar landscape that takes time getting used to (remember the first time you ever worked with HTML and CSS, its just like that)
    • Its very picky and unforgiving, one wrong move and you get an very unhelpful BAD PARSER error forcing you to literally dig through all of your code to try and figure out what the problem it.
    • Blend, it’s a whole new tool (even if you already know Adobe Photoshop)
    • You have to find your way around the tool, its not obvious how to do a lot of things , expect to spend lots of time and energy getting used to it
  5. Visual Studio and Blend: it takes two to tango
    • You really must have Blend in order to develop complex (or even average) Silverlight applications
    • Animation and themes are pretty much done exclusively in Blend.
    • All your C# coding is done in Visual Studio
    • Reliable Error message don’t exist, this increases the time and difficulty in tracking down issues.
  6. Gotcha’s that will drive you nuts
    • If you don’t explicitly set the Forecolor (a.k.a the font color) on your TextBlock then your text wont show up (even though it looks fine in Blend)
    • Your project can get out of synch when working in both Blend and Visual Studio, if your not careful you can end up undoing a lot of your code
    • The Design View in Blend can screw you! Don’t rely on it exclusively, instead always be looking at the Code Window (Split View) when working with the designer
    • No Project Refresh in Blend: After adding items to your project through visual studio you have to trick Blend into reloading the project in order to work with the additions.
    • Bland fails to apply namespace properly when using it to add new User Controls
    • Selecting an Image source through the designer copies the image to the Silverlight Application Root
    • Blend doesn’t recognize Web Service References and will indicate that you have errors when you really don’t
    • Error Message are worthless.

Understanding the basics

  1. UI layout
    • Grids: they are very much like HTML Tables
    • Stack panels: this is like an HTML Div where you set the “orientation” of its contents to one of two setting, either Horizontal (default) or Vertical
    • Canvases: just like it sounds, it’s basically a container where you position its content using Canvas.Top=“x” and Canvas.Left=“x”. Very similar to using a Top and Left in HTML/CSS
    • Margins: allow you to add spacing between items (left, top, right, bottom) in order to control its position relative to other objects. Just like Margin/Padding in HTML/CSS
  2. Animations
    • Visual State Manager: this is the build in “animation” that is applied to object. Is usually developed using Blend because it can be a nasty little bugger to work with by hand.
    • Animation using Blend: similar to how you animate object in Flash (“Tween” like features as well as Easing)
    • Behaviors: these are “In-Code” animations (basically taking an animation that Blend creates and writing it in C#). Can be reused through your project as well as other projects (by adding references to the DLL its contained within). Not easy to create because currently there isn’t any automation tools to write the C# code (you will be doing by hand, not fun).
  3. Events and Data-Binding
    • Getting a grip on Asynchronous Data Exchange: timing is everything, your data may take a long time to return (if it returns at all) and you need to let people know what’s happening during this time. Data returned is not guaranteed to be returned on the User Interface Thread, meaning it may be there but not show up in the UI
    • Data-Binding and why it’s so awesome in Silverlight: Binding objects to data is INSANELY easy. Objects look for data that it should bind to first in its own DataContext, then its Parent, then its parents parent, etc… until it finds (or doesn’t) what its looking for. Handles “not found” very graciously.
    • Accessing your web services: set-up to easily handle moving from Dev to Test and then into the Production Environment
    • Wiring events to User Controls: very similar to how you define it in ASP.NET web applications.

References assemblies & debugging your project

  1. Accessing and Using Shared Components
    • Using Blend’s Control Library to access items in referenced libraries. In Blend you can access controls that exist in references library (DLL’s).
      Blend
    • Extending existing controls in order to customize them: accomplished in the same way as ASP.NET, simply create a Class file that inherits from the base control (i.e. the Textbox control) and add custom properties and methods to it. Then use these in your project in order to take advantage of the added functionality.
    • DLL’s as well as “Behavior” classes (just C# class files), many available for Free on the Web (visit http://gallery.expression.microsoft.com/en-us/  )
  2. Testing and Debugging your application
    • Using Fiddler to intercept web service requests (very useful to debug web-service requests and responses)
    • Using Silverlight Spy to identify User Interface elements (a must-have tool to drill down on the Silverlight objects displayed on the screen)
    • Unit Testing your Web Services and Business Logic