Blog Home  Home RSS 2.0 Atom 1.0 CDF  
The Efficient Coder - .NET 3.5
There has got to be a better way of communicating with our computers!
 
 Sunday, November 16, 2008

Early on in my career I was mentored on deferring execution.  This was in a language called FORTH and the idea was build your program structure and abstract the details into WORDS to be filled in later.  Repeat until complete.  This simple process still holds true today in OO languages like C# where I do most of my work.

Now back to why I like Silverlight/WPF, as I'm just starting to get beyond the basics, the more I'm starting to see that this is an extremely well thought out architecture.  As I'm developing my functionality I can easily "defer execution" or really in this case, care zero about the style and then go in later and make it pretty.  Or if I'm really lucky find someone that knows what they are doing to give it a polished look.  Although the same can be done with HTML and CSS, this just seems like it's just a bit cleaner and since we are targetting only one type of client (Silverlight or WPF) instead of the different browsers the results are much more repeatable.

The other thing I'm really impressed with is the separation of UI and code behind.  Although time will tell on the actual business value (read ability to maintain and extend) it seems like the ability to create CLR instances in the XAML and then glue everything together with dependency properties, just feels good to do.

Now back to getting some work done with this!

-ec

11/16/2008 1:56:42 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   .NET 3.5 | ASP.NET | Silverlight  |  Trackback
 Wednesday, June 11, 2008

I've got a couple mobile projects that need to provide communications services to a centralized server.  Over the past year or so, I've been getting to know WCF a little better and the more I learn, the more I think this is the one by far that in all the latest Microsoft technologies, that you should invest your time in learning.  Saying that, it would seem logical to think about using WCF as the technology to communicate on our mobile devices.  I'm not sure the answer is clear to me yet on this one.

First, what do I LOVE about WCF, if I had to sum it up, I would say three things,

  1. The formality of defining and implementing contacts for our communications
  2. The ability to configure and for the most part not worry about the transport details when coding your service
  3. The ability to do duplex messaging, I still need to spend some time to see how this works under the hood from a scalability implication, but the concept in general seems powerful.

Saying that, we can make the following assumptions about the current state of mobile devices and applications:

  1. In most cases the device is going to be a client on the client/server side of the equation
  2. Our computing horsepower just isn't the same
  3. Based upon my experience in both worlds (desktop/web AND mobile devices) I would say you can crank out 3-5 lines of desktop/web code in the same time it takes to get one line of mobile code into production
  4. Code on mobile devices can't easily be updated so it really has to be right the first time
  5. As good as our mobile platforms are these days, there are still a few quirks that are beyond our control and device specific

Therefore, most of the benefits of going with WCF really aren't that great in a mobile device.  And if a technology really doesn't provide much value, it may make more sense to keep it simplest technology with the fewest moving parts.  I think as with anything new, one needs to implement and analyze the results.  As I mentioned earlier, I don't have answers here yet, but wanted to start capturing thoughts.

-ec

 

6/11/2008 7:08:05 AM (Eastern Standard Time, UTC-05:00)  #    Comments [2]   .NET 3.5 | Mobile | WCF  |  Trackback
 Thursday, June 05, 2008

Annoying VS.NET "Feature"

 

I have a fairly large ASP.NET application that has a large number ASP.NET WebParts built as Custom Controls (150+) in a compiled assembly .  I've been getting a little annoyed with VS.NET (I'm using 2008 right now, but saw the same behavior in 2005) where after I get done compiling I have to wait 20-30 seconds while VS.NET does ?something? and freezes the UI (can't ?someting? this be done in a worker thread).  Anyway I think I've finally figured out what's up, it would appear anytime I open anything that requires a designer (including an ASMX page) the tool box get's populated with all the custom controls as part of my project.  It would seem as soon as the tool box is populated it needs to be refreshed and that's what's taking the 20-30 seconds.  So therefore if I don't open anything requiring a designer, I'm OK.  I think I've gotten used to this for ASPX and ASCX pages since they normally open up in the HTML view, but I'm still clicking on ASMX and Services design surfaces and end up shutting down VS.NET and restarting without a design surface open.

 

Maybe my project isn't typical, but it sure would be nice if I could use design surfaces at some point.

 

-ec

 

6/5/2008 7:08:30 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   .NET 3.5 | ASP.NET  |  Trackback
 Saturday, May 24, 2008

LINQ 2 SQL - SQL Server Compact Edition 3.5 - Provider Not Found

If you are working on a 64 bit machine and get the error message

Provider 'System.Data.SqlServerCe.3.5' not installed.

when you attempt to connect to your database, open your project properties and on the build tab, change your target platform to x86 and you should be back in business.

-ec

5/24/2008 5:48:29 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   .NET 3.5  |  Trackback
 Sunday, May 11, 2008

More Help Available

I got this one while trying to spin up a 3.5 WCF Service and it made me chuckle...no comment necessary...

-ec

5/11/2008 2:33:36 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   .NET 3.5  |  Trackback
 Monday, November 26, 2007

Upgrade to .NET FX 3.5 - Assembly Binding

I've officially converted my main ASP.NET application from 2.0 to 3.5 this morning overall it was very painless, for the most part, just adjust the class libraries to use the .Net Frameworks 3.5, and modify web.config entries from System.Web.UI.Extensions, Version 1.0.61025.0 to System.Web.Extensions, Version=3.5.0.0.  The problem I ran into was that some of the control libraries I was using were compiled against the 2.0 framework.  Adding the following keys to the bottom of my web.config files clean that up.<configuration>
  ....
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Extensions" publicKeyToken="31bf3856ad364e35"/>
        <bindingRedirect oldVersion="1.0.0.0-1.1.0.0" newVersion="3.5.0.0"/>
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Extensions.Design" publicKeyToken="31bf3856ad364e35"/>
        <bindingRedirect oldVersion="1.0.0.0-1.1.0.0" newVersion="3.5.0.0"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

-ec

11/26/2007 11:41:35 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]   .NET 3.5 | ASP.NET  |  Trackback
Copyright © 2009 Kevin D. Wolf. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme: