Sunday, June 24, 2007

Silverlight with Visual Studio 2005

If you are trying to use Silverlight with Visual Studio 2005 there are a few issues to watch out for. Bryant Likes has created an article that contains the steps and a sample class library dll to act as a wrapper of the Silverlight binaries. I have included an excerpt below the link as well as a few issues I have found on other websites related to Silverlight and Visual Studio 2005.

http://blogs.sqlxml.org/bryantlikes/archive/2007/05/02/silverlight-hello-world-in-c-from-vs-2005.aspx

Well, in VS2005 you can create a class library which will build against the Silverlight runtime, but it's a little work.

  1. Create a Class Library.
  2. Remove all references from it.
  3. Right-click on the Project and pick Properties.
  4. On the Build tab, click Advanced and check 'Do not reference mscorlib.dll'
  5. Manually add references to mscorlib, agclr, System, System.Core, System.Silverlight, and System.Xml.Core from the Silverlight install folder (\Program Files\Microsoft Silverlight\) At this point your build outputs should be Silverlight consumable binaries. It looks like the equivalent command line call to csc.exe (the C# compiler) should include the references to the mentioned binaries and the /nostdlib option but may require others as well. -Scott

You may also want to check out this article as it mentions a couple issues you may run in to: http://silverlight.net/forums/t/370.aspx
Here is a summary:

You may get the following error message:
Silverlight error
message ErrorCode: 2252 ErrorType: ParserErrorMessage:
AG_E_RUNTIME_MANAGED_ASSEMBLY_DOWNLAODXaml File: Page.xamlLine:
7Position: 9
That's a common error message whenever the Silverlight runtime
can't get to the assembly. Usually either IIS isn't serving the DLL to browsers
or the path in the Xaml file to the assembly is not the right path relative to
the HTML page or Web Form consuming the Silverlight content.
Issue 1: IIS
not serving the DLL to browsers.The easiest way to check this is to manually
give the browse the URL to the DLL itself and see if you get the Open/Save
dialog from IE. If you do, the assembly is being served correctly. If you don't,
IIS isn't configured to serve the assembly. For us, this usually happened for
Virtual Directories which were configured with 'Execute Permissions' set to
'Scripts and Executables'. Run the inetmgr tool, right-click on your Virtual
Directory, and look at the value for Execute Permissions on the Directory tab.
It should be 'Scripts Only' so that IIS tries to serve the assembly as a file
rather than looking for an entry point to execute it.
Issue 2: Assembly path
isn't relative to the web page consuming the Silverlight contentCurrently the
Xaml files need a path to the assembly (like ClientBin/SilverlightProject1.dll)
and while the path is in the Xaml file, it's evaluated relative to the HTML page
or Web Form using the Xaml. So, if your Web Form is http://myserver/mysite/TestPage.html
and your Xaml file says to look for ClientBin/SilverlightProject1.dll, the
runtime will look at http://myserver/mysite/ClientBin/SilverlightProject1.dll.
Make sure the Xaml file and consuming page are in the same folder, or modify the
path in the Xaml file so that it's relative to where the consuming web page will
really be located. We're working on a better solution to this problem so that
the Xaml file doesn't need to know about the consuming page, but for now the
easiest solution is to put them in the same location.
Another user commented
that they fixed this issue the following way:
In my Page.xaml file I changed
the assembly=silverlight1.dll to assemby=bin/Debug/silverlight1.dll and finally
everything started to work.
Also another issue that will raise the parse
error is the location of the compiled Class Library *.dll file.
The
Silverlight 1.1 runtime requires the dll to be downloaded to the client. Some
web server configurations won't allow dll's to be downloaded from the standard
Bin or Cgi-bin folders which is where one typically sticks compiled dll
libraries. The easiest way is to just place it alongside your other xaml assets
while keeping in mind the above caveat of remembering the path is relative to
the page calling the xaml object.
I found another situation where the
ClientBin path gets messed up. Create a project with a name of the form A-B, the
namespace becomes A_B, the xaml file has assembly=ClientBin/A_B.dll, but the dll
is built as ClientBin/A-B.dll

Hope these excerpts of errors and issues with tips to fix them was helpful.

If you run into issues using Silverlight with Visual Studio 2005 please email them to me.
Also, if you know any Tips or Tricks I can add to this blog please email them to me at chrisw_88@hotmail.com

No comments: