{ XNoDE }

WCF vs. *.ASMX

2008-10-15T10:40:31.577-07:00

.NET Dojo (WCF vs. *.asmx)

Recently I attended the .NET Dojo event here in Houston, where Steven Fulcher talked about WCF and its implementation. Early on, I found myself trying to figure out how I, as an ASP.NET developer already using *.asmx services, would truly benefit from this technology. At first glance, you might take it as a proprietary wrapper SOAP, POX (plain old xml), REST and other web programming models that already exist. However, as we plowed forward through the examples and hands-on labs, the power and flexibility gained by adding WCF to your distributed architecture becomes prevalent.

I won’t go into a lot of detail but simply point out the feature that stands out to me, WCF Security.

By making simple configuration changes, the data returned by your service can be encrypted, even over http://.

…other stuff here

<endpoint address=""

binding="wsHttpBinding"

contract="MyService.IMyServiceInterface" />

</service>

</services>

</system.serviceModel>

By modifying the endpoint configuration in your web.config or app.config , depending on what type of service host you choose, setting its binding to “wsHttpBinding”, you will encrypt the data. This is something that isn’t possible via the *.asmx services that are currently being used in many applications.

There are many tutorials and labs available at: http://msdn.microsoft.com/en-us/netframework/aa663324.aspx so take a look.

Converted To The MAC...OMG!

2008-05-16T11:27:10.239-07:00

If someone had mentioned a week ago today that I would be a "PROUD" owner of a MacBook Pro, I would probably reply, "shist, yeah right". Well as I type these words today, I would have to eat those. Yesterday I took the plunge and purchased MacBook Pro and I have to admit that I am impressed by far with the system.

If you read an earlier post "Overheating Laptop!" then you are familiar with the computing woes that plagued me over the past couple of weeks and thus left me shopping for a new primary laptop.

After a week of comparison shopping and some coaxing by some friends (?)…I was convinced that I should give Mac a try. I am yet to be disappointed.

Features that totally rock:

Boot Camp:    Wouldn’t be able to survive without it. The hidden utility that is bundled in the OS, makes partitioning the hard drive and installing Windows Vista seamless. It even sets Vista as your "DEFAULT" operating system so that when you power on, you’re in Windows Vista. How's that for humility?


Parallels:   So booting directly into Vista is nice, but why buy a Mac to boot into Vista. Yes, I need Vista for development, but I bought a MacBook to boot into Mac OS X.

By downloading and installing Parallels, I was ready to go in about 30 mins. Parallels is a virtual desktop application that allows you to run a virtual computer while using your current computer. It's awesome because it detected the boot camp drive and connected to it as a virtual system so that I didn't have to install another copy of the OS. Presto, I am in business!

Bluetooth Mouse:    Love the programable buttons, love the touch > click memory (touch right side with one finger = right click).

Time Machine:   Very cool backup tool. In essence takes a snapshot of your system at a given point in time. Essentially System Restore on the Mac except with a cool ass interface.

iChat, Built-In WebCam, and Microphone:   Amazing!

Bluetooth Hardware and Software installed: Awesome!

DVD Authoring Software!

Imagine…drag and drop a pic directly from a web page to your desktop, library, or document with no right-clicking.

To add to that, installing applications without stopping what you are doing and without restarting…nice!

Well you get the point. So I am finding computing fun again...wicked.

Windows Vista "Aero" UI for ASP.NET GridView Control

2008-05-15T08:38:37.054-07:00

Kevin Brammer has a post hightlighting how you can apply Vista's Aero theme to your ASP.NET GridView controls. The graphically challenged person that I am, I thought the post to be good stuff.

ClickOnce Deployment and Visual Studio 2008 (A Small Gotcha)

2008-05-14T10:23:12.359-07:00

ClickOnce is a great new feature in Windows application development that provides a simple application deployment and update model. While it isn’t the most comprehensive and robust solution, I find that it works for deploying and updating small scaled applications. However, I did find one issue that could easily be overlooked and cause your updates to fail.

In toying around with one of my applications, I began to receive the “DeploymentDownloadException” exception. Upon reading further into the details, I found that my IIS Server was returning the HTTP Error Code: 404 (file not found).

So I opened the project’s properties page to confirm the upload and deployment locations; they were fine. Then I launched FileZilla (ftp client), to view the directories and found that the Publish from VisualStudio had run successfully because the files had been uploaded.

Puzzled, I went back to the error dialog, and read the detailed error message again. I discovered that the .application file was not found and couldn’t begin to understand why it wasn’t uploaded.

Because the updates for this particular application had worked fine before, I knew that it must be something involving my last actions. So, what was my approach to solving this issue you ask?

Well, to use the highly effective and scientifically mystical “think back or re-trace your steps” method of course.

The problem…

By default, the Publish Wizard in VisualStudio saves ClickOnce applications with the .application extension appended. However, the Publish feature in the Properties dialog allows you to save the application files with a .deploy extension. Well if you publish your application using the Properties dialog with the “use .deploy extension” option checked, and then publish a later revision using the Publish Wizard, then on attempting to update the application, the server will return an HTTP 404 error. This is because your original dll has the .deploy extension appended to it and not the .applicatIon extension that the Publish Wizard added.

The solution…this is really tricky, so pay close attention:

Don’t combine the publishing methods. If you use the Publish Wizard to start, always use it; if you use the Properties form with the “use .deploy extension” selected, then always use the properties form.

Oh, and to fix and existing issue, simply published again using the original method and the application will be back on track.

Happy ClickOnce’ing!