I think WinForm applications mostly uses for companies which want their own softwares, not for shareware applications inside internet or other places cause .NET framework still is not part of operating system and should be download seprately. I myself wrote all of win applications for my customers in C# this year(or last year ) and one of them was international oil company of Aaustria in Iran and its a really big company.
We have one I architected (though more time to design it would've been nice, but you may know these rush-to-market start-ups can't fathom that!) a while back (started designing on 1.0 RC1) at http://www.proplanner.com[^] (the site looked much better after I wrote the initial bits until marketing got ahold of it!).
It uses just about everything: RCWs (for now - they are being replaced with .NET equivalents as they become available since we don't have time to write such libraries), .NET Remoting, Web Services, Windows Forms, ASP.NET, and massive amounts of ADO.NET.
The biggest complaint thusfar is the 20+ MB runtime download as well as the req' of admin access to install the .NET Framework (you wouldn't believe how long it took me to explain to my CEO that there is just no way around this requirement!). Otherwise, the application uses a no-touch deployment across the Internet (we have a LAN version that talks directly to SQL Server, too, built on the same code with different proxies) so the assemblies are cached in the Temporary Assembly Cache and we control versioning easily in the assembly repository online.
I do know for a fact that a lot of companies are writing in-house applications using .NET for RAD (rapid application development) because their IT can easily deploy the .NET Framework to machines and it cuts development costs and doesn't always require true geeks to do (don't get me started on that!).
I think that as "Longhorn" comes to fruition, we'll start seeing more. .NET is definitely being well-received for many things so I think it's wide-spread use is inevitable. It's been released for a couple years and is still going strong, so that's always a good sign. I think the only reason Java spread much more quickly (and I remember the Java-boom well) is because of Java applets and the fact that we never had anything like that (rich clients) before.
I've been under the general impression that the commercial .NET applications are primarily oriented toward specific business types or tasks. This sort of software is marketted in a way that the clients are likely to not even know that .NET is being used, and are even less likely to care before purchase of the product. (If it works, we want it.)
Anyway, our company as been using .NET at client sites for well over a year now (maybe 2).
"You said a whole sentence with no words in it, and I understood you!" -- my wife as she cries about slowly becoming a geek.
I have a question, so if you have some ideas, please tell me.
I'm developing file download tool using WebClient class.
But I have a trouble. After downloaded file, I checked it.
The file's timestamp changed to be downloaded time.
I'd like to get how to download file not to change timestamp.
I'm looking for some solution, but I can't.
The following is file download routine.
wc = new WebClient();
myCache = new CredentialCache();
myCache.Add(new Uri(sFrom_Download),"Basic", new NetworkCredential(sUser, sPassword));
wc.Credentials = myCache;
Do you mean the timestamp of the original file on your filesystem, or do you want to use the timestamp of the file that was on the server?
In the former case, if the file exists (see File.Exists) get the last modification date by using a FileInfo that points to it and store the FileInfo.LastWriteTime. After you finish writing the file, set the FileInfo.LastWriteTime to the DateTime you stored previously.
In the latter case, don't use the WebClient; use the HttpWebRequest and HttpWebResponse which are very easy to use and very robust. They are built on the asynchronous pluggable protocol system of .NET and if you look at the documentation for either of those you will find many useful examples.
So, after you make your request and call HttpWebRequest.GetResponse (and cast it to a HttpWebResponse), you can get the HttpWebResponse.LastModified date. AFter you write the file using a buffer, again create a FileInfo instance pointing to that download file and set the FileInfo.LastModified date.
Does anyone how to solve this problem. When I load my XML file with System.XML.XMLDocument. I get this error message
An unhandled exception of type 'System.Configuration.ConfigurationException' occurred in system.dll<br />
Additional information: Error loading XML file c:\winnt\microsoft.net\framework\v1.0.3705\Config\machine.config Request for the permission of type System.Security.Permissions.StrongNameIdentityPermission, mscorlib, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed.
The exception is thrown by the CLR when you don't have the specified permission. In this case, the requested permissions is a StrongNameIdentityPermissions. Reading the machine.config is a protected operation (it contains machine-sensitive information) so you're assembly has to be signed (and honestly, it should anyway).
To sign your assembly, generate a key pair (public and private keys) using "sn.exe -k KeyFile.snk" and put it somewhere safe. You should actually try to use this for all your code, but do not distribute it to anyone but - if applicable - your development team (unless you use late-signing and have a build master). Make sure you have an assembly-level AssemblyVersionAttribute and either an AssemblyKeyFileAttribute or AssemblyKeyNameAttribute. If you created your project with VS.NET, you will find these in your AssemblyInfo.cs file (but the can be placed anywhere so long as they're prefixed with [assembly: ...]). This creates a strong-named assembly.
Read the documentation about the AssemblyKey* attributes toward the bottom of the file. It's also recommended in multi-project solutions that you do not use a automatically-generated version number because things can easily get out of hand.
I have just converted a Console application to a class library. When I tested it out, it does not seem to find the configuration I have specified in the App.Config. It reads the configuration file fine when it is an console app.
How do I specify the configuration file that goes with the class library?
A configuration file is associated with an application by the loader. For applications executed from the shell, the app loader creates an unmanaged _AppDomain which creates an AppDomain, set the AppDomain.SetupInformation.ConfigurationFile to the path of the application file plus ".config", and executes the entry point. The .config file must therefore be named "MyApp.exe.config" and be in the application path. For a smart client, the same rules apply or the IEExec.exe application will also read the <link ref="configuration" href="path/to.config"> in your HTML document's header. There is nothing like this documented for a CCW (COM-Callable Wrapper) but last time I tried creating a .config file for the application that uses your COM object using the naming convention discussed above (even though the application used java.exe) the CCW was able to read it (the AppDomain setup by mscoree.dll in which, by default, your CCW is hosted) apparently uses the executable name still).
I guess I do not understand which name it is looking for...
I have a class library, xyz.dll, which I export a class MyNamespace.MySubNamespace.xyz via System.Runtime.InteropServices. What configuration filename will mscoree.dll look for? xyz.dll.config or xyz.config or MyNamespace.MySubnamespace.xyz.config.
I think I have tried them all.. it does not seem to work.
Can I setup something in mscoree.dll?
You have to name the .config file according to the executable (.exe) naming convention for whatever application instantiates your control. For instance, lets say you want to test you control in the ActiveX Control Test Container (tstcon32.exe). You would put a txtcon32.exe.config file in the same directory as txtcon32.exe. Last time I tried this (some time back) it worked. Give it a try now. The ActiveX Control Test Container would be a good test without having to write a new COM client, too.