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.
I am trying to use remoting to allow a client access to an object that has already been instantiated on a remote server. My thought was that I could create an object that would be offered up by remoting to clients which would have a reference to this already instantiated object, that way clients would be able to get at this variable which contains state information about the program running server-side. However, after reading about remoting from several different sources I am unable to figure out how to actually pass this reference to an existing object into the object that will be offered to the client over remoting.
If anyone can provide me any insight into this subject, I would be greately appreciative.
The window frame is not part of the form and has to be handled differently. In the case of the frame for you main form, you can use an IMessageFilter implementation to get notification of a click:
publicclass Test : Form, IMessageFilter
Test t = new Test();
this.Text = "Test";
bool IMessageFilter.PreFilterMessage(ref Message m)
if (m.Msg == WM_NCLBUTTONDOWN)
MessageBox.Show("You clicked the Window frame");
privateconstint WM_NCLBUTTONDOWN = 0x00a1;
See documentation for the WM_NC* messages for more information about non-client notification messages that you can handle in an IMessageFilter implementation.
I'm curious as to what kind of market penetration C# has achieved in the freeware/shareware/hobby-ware application segment. It seems that virtually everything that you see on sites like Download.com are still written in Visual C++ or VB. Am I wrong about that, or has C# been embraced by developers and users of this classification of applications and utilities?
I'm not too surprised, honestly. I see the same thing. The main reason, I believe (based on feedback and community involvement), is that .NET application require the 20+ MB runtime to be installed in order to run (and sometimes even install if Installer derivatives are used as Custom Actions in an MSI). For free/shareware, this is too much of a burden on would-be users (after all, why download crap...er, helpful utilities when it requires such a heft download or such large prereq's).
Another reason - though this is greatly generalized and is not even based on a stereotype - is that some free/shareware developers aren't what you'd call "up-to-date" and can't find tech jobs, so they use what (little) they know. I might get flamed for this (and remember to those who are considering flaming me that I said some), but after looking at betanews.com every once in a while I see a lot of examples that support what I said (butdon't get me wrong, there are a lot of good programs posted there, including some from Microsoft and other large companies).
There are a few examples of that around (SharpReader is a good example of a non-programming-oriented program), but it is true that the size and hassle of downloading the CLR makes it less convenient for the end user. And there is inertia, both in programmers and in their existing code.
On the other hand, it's generally much easier to write a windows program in C# than it was in C++.
Eric Gunnerson (msft) wrote: On the other hand, it's generally much easier to write a windows program in C# than it was in C++.
Yeah, that's why I'm surprised more people haven't flocked to C# as the language of choice for hobby-development. I'd guess that given the number of people with broadband these days, most people probably have the CLR installed, don't they?
I think one thing that is increasing the inertia of ".NET" is that it is becoming more and more of a buzzword for program managers on up in larger corporations that want to move in this "new" direction. My CEO decided on it even before he knew exactly what it was (good thing he hired me to architect it since I had about a year of experience starting with the 1.0 betas). Of course, this is extreme (and extremely stupid) but I see it happening more and more.
We do, as you can easily tell, have a .NET application and bootstrapping the CLR has been a problem, especially since the bootstrapper that Wise uses for the MSI product doesn't force the selected runtime (if a newer one is installed, it doesn't bootstrap the .NET installer). When I get time (someday it won't be hard writing a new one, but we have had complaints from people trying our software out that the .NET runtime is just too much of a hastle. This is an Internet-deployed smart client, so they have to take the time to download and cache (ala Fusion) our application as well.
I do forsee this picking up when Longhorn reaches fruition, but wide-spread adoption of that I'm sure will take time (especially since it requires a much beefier machine).
So long as people keep up-to-date with Windows Update (and I know that has been a problem Microsoft has been trying to address and push...and I agree they should), they should have it. Perhaps when more free/shareware developers take note of this they will reconsider.