>>>
>>>Now all that said I would highly consider NOT building desktop applications. If your apps are line of business applications consider building Web based applications and running them locally or on a local network instead. The apps become immediately distributable, tend to be easier to maintain and grow and you're not directly stuck with Microsoft's Jeckyll and Hyde's identity crisis when it comes to UI.
>>>
>>>This is the path I've taken for the last few years and I'm not regretting it. All internal stuff now runs in the browser and it's simply easier to maintain, expand and intermix Web based UIs. Plus you can access them from anywhere, and when I travel I can get by with a tablet often where I needed a PC before.
>>>
>>
>>Sounds like a great strategy to me, but I am wondering, how do you solve printing of documents in applications where printing activity is still intense? Am I right in assuming that the pc's have fixed ip's and it is the server that initiates the printing jobs?
>
>Good question.
>I'm working on a browser-based app now and the printing is the most difficult part of the app.
>You can ask the same question about other peripherals.. scanners, etc., or interfacing with apps like Exel, etc and the answers will be fuzzy.

Thanks. For a moment there I thought I was the only one who was missing something.

I guess that you can still use in excel in com (via interop, I've been doing it in VB.net) on the server. You won't be able to open the created spreadsheet in excel for the user though. Ah well. :)