Questions and Answers on any aspect of .NET. Now closed.
Hi - Does anyone know of any currently shipping desktop .NET Forms applications? (Not so much shareware or small tools, but decently-sized thick-client type apps) Any links would be much appreciated!
This question is actually related to another one: while all material points to obfuscation for .net clients as a 'good idea' it's not clear whether any sort of protocol or best practices have emerged here. Does anyone know whether it's a fairly standard market practice to introduce some sort of code protection for byte-code distributed apps? Any sources or references would be enormously helpful.
Jetbrains Omea, Omea Reader, and Resharper
It's not released yet, but it will be very soon...
Microsoft Small Business Accounting
I don't know if they use an obfuscator.
I was just about to ask this question.
I'm at the point where I have to decide whether to develop our shrinkwrap software with C++/MFC or C#/WinForms (Whidbey). This is a large scale consumer audio application we are aiming to ship one to two years from now. I've been using MFC up until now and finding it to be a huge hassle. I think I could be a lot more productive with C# but I'm worried that it's not proven tech for shrinkwrap software, although it might be by the time we ship.
So should I go with something that looks superior but may harbor hidden roadblocks or stick with something I know is horribly inefficient but tried and true?
Jason: You have to obfuscate you code. If you don't you are distributing the source code with your application. Even with obfuscation you are only making the task of reading your code more difficult. When you obfuscate watch out for reflection: the type names are changed but any string literals referring to the types are not so you have to exclude those names. Also you MUST test the obfuscated code completely.
Jedediah: I've released a shrink-wrap WinForms app. I wouldn't do it again. Rather then simplifying distribution I think .Net has made it worse. There are currently three mainstream .Net runtimes your users may need to have on their systems. In two years there could be five. It’s ridiculous. The only thing it has accomplished is to relieve Microsoft of the need to have backwards compatibility in their development tools. For further reference see http://www.joelonsoftware.com/articles/PleaseLinker.html
Have you looked at WTL instead of MFC?
Obviously Anon, can you give me more details on what your problems were? I was under the impression that if you target your code to a certain version of the runtime then it will always use that version and multiple versions can co-exist on the same client without interfering with each other. I also assumed that I could distribute the runtime with my app and make it a seamless part of the install process. My users are novice consumers so I can't tell them to go download something from Windows Update.
As for WTL, I had a look at it but wrote it off due to it being unsupported and not being able to make it work along side MFC. What do you see as its advantages over MFC?
Jedediah: I faced three types of problems distributing a .Net app. The first was the size of the downloads needed, second was difficulty with being tied to third party libraries/assemblies, and the third was being tied to a moving target for development.
The first problem was an issue because I wanted to have a free download version of the application. The target market for the product is small businesses. They typically don’t have .Net installed. Yeah with a high speed connection the 20 MB download isn’t that bad but it is a reason for your potential customers to walk away. What made this worse was that you don’t have to distribute just the runtime. The runtime is not a standalone framework no matter what you may have read. For example if you are doing any ADO.NET you also need to distribute the latest MDAC.
The second problem has to do with being tied to a specific runtime release by using third party assemblies. In my case I used managed DirectX. What blew my mind was learning that people could have a later release of DirectX installed and be incompatible with my application. The application is tied to a specific release of DirectX by the assembly version. The result is that I have to distribute DirectX to people who already have it to insure that they have the correct version of the managed library. That added 37 Meg to the distribution. So yeah you can have multiple versions installed side by side but you have to insure that you have all of the third party assemblies the correct version.
The last problem is being tied too closely to Microsoft’s latest development tool. Beyond the need to develop with a beta product (and you must other wise you’ll be out of date when you ship) you immediately have added versions of your product to support every time a .Net version is released.
In summary you save time because the development tool is so much better but you lose all that and more do to other problems.
As to WTL: I’m not an expert on it at all. I played with it because it seemed pretty cool (a decent windows framework without the crap of MFC). I haven’t done anything large with it. I mentioned it because it seems to fill the space left for developing win32 applications. There is a version of it on Sourceforge since it has been made open source by Microsoft.
Last I heard, Microsoft's intention was to move all Windows development over to .net so I'm very curious how they're planning to deal with these problems.
Don't quote me on this, but I think the final version of Whidbey is going to let you specify the target runtime since so many people were demanding this.
You can always specify a specific version of the runtime via a .Config file. This has been baked into .NET since V1.0. And if you don't provide a .Config file your application is automatically forward compatible - if a new version rolls around it just runs (assuming that the newer version doesn't break something - there are a few things that break, but overall forward compatibility is well over 99% between 1.x to 2.0).
Runtime size is definitely an issue and there are no workarounds for that as is the fact that many 'external' interfaces like DirectX and Office Interop being tied to very specific versions as described above.
For shrinkwrap applications .NET is a mixed bag. .NET offers a trade off: Development ease vs. deployment flexibility and you have to carefully choose which one is right for you. I personally feel that shrinkwrap .NET apps are not a good choice in many situations, but higher capacity connections reduce at least the size issue more recently. Dealing with versioning and fairly steep hardware requirements are probably more crucial for broad market application than anything else. But it depends who your market is really - if you're dealing with your average Mom and Pop consumers, .NET is going to be a tough sell for desktop apps.
Saturday, September 10, 2005
My company ships three moderately hefty apps, all based on .NET.
Unlike O-A, we're perfectly happy with .NET.
For government/corporate customers, the use of .NET has never been mentioned as a problem. Downloading the .NET runtime might make our software unattractive for smaller customers. We don't collect stats to compare people who downloaded vs people who actually get our software running, so I cannot say. I might put some logging into the next release of our reporting tool for Groove Forms...
We don't rely on any software that we cannot manage the relationship with - if I was going to depend on specific versions of DirectX, I might be tempted to rethink.
ALL our software development has been done on release versions of .NET. I don't know if that means our apps are not 'decently-sized thick-client type apps', or whether we're just a hyper-productive bunch. :-)
OP - see my sig for links.
Friday, September 16, 2005
ATI Driver Catalyst 5.9
Thursday, September 22, 2005
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz