For me satellite assembly mean is when you create an application using feature like globalistion and localisation, create resource to extract region specific information. In this senerio the assemblies behave according to region ....
Jaiprakash M Bankolli
I find (especially in .NET 1.1) that many UI type classes are kept "sealed". Any specific reason for that?
Examples: Classes like Tooltip, Progressbar etc.
Typcially, UI classes are supposed to be extensible. I can understand if 3rd party vendors keep their UI classes sealed (for more business oppurtunity ) and therefore only provide developers to extended the functionality by providing properties or other extension mechanisms like interfaces on the controls/components (for custom rendering of the component) etc.
But why would Framework providers like Microsoft, keep their (of course, not all!) UI classes sealed?
One particular reason is so that you can't end up doing something that breaks the underlying object. Bear in mind that some of the controls are effectively wrappers for API calls you can appreciate that it would be very easy for you to do something that just broke them.
Deja View - the feeling that you've seen this post before.
My understanding is that classes like Tooltip etc are final form of any feature/ UI type. If you try to customse it you will not achieve much ... so they are SEALED. This make the developer use it as it is in either custome or user control
Jaiprakash M Bankolli
My unmanaged C++ application (MFC) is consuming events provided by a .NET object exposed by a VB.NET application (.NET 1.1 is used). Things were working fine till yesterday. But today, when I tested the executables on the same test PC, the client hangs.
Further analysis revealed that the client was able to create the object in .NET application using IDispatch call, then find connection point successfully. But it hangs when it tries to call IConnectionPoint::Advice.
Following is the call stack of the thread (I created dump using adplus.vbs in hang mode)
This is more of a Muse than an actualy question, but answers would be welcome.
I find occasionaly that i may use an object for a short period of time and after that, never want to use it again. It seems a waste to let something go through the full GC process, when i could kill it there and then.
An example would be a StreamReader that i use to read an input stream. It only exists in the scope of the function, and at the end of that it will no longer be needed. If it existed I could just call GC.Kill(reader) and be done with it.
It's already cluttered up to death anyway. All strings are immutable objects. String manipulations create and destroy lots of small objects, that just hang around until the GC gets around to collecting them.
It's a nice idea on paper, but it also introduces problems that can't be fixed until the next GC, like memory fragmentation. The GC maintains the managed heap, compacting memory when it can and when it needs to. It's performance is also self-tuning. Having you just kill and forcibly collect any object you want just destroys the ability of the tuner to do it's job.
Your idea is actually introducing the ability to create more clutter for the GC, not less.
Dave Kreskowiak Microsoft MVP
Visual Developer - Visual Basic 2006, 2007
Is there a way to run a native Windows application if .NET is not installed on the target machine?
There was a way to do this with MS-DOS and Windows applications, by attaching a stub[^] application to the main executable. Then, if the application was launched in MS-DOS, the stub would run instead, usually providing a suitable error message.
You could create a stub, written in unmanaged C++ that MIGHT work
Yes, but how?
The MS-DOS stub was trivial - it was just a one line .EXE that told you to go get Windows. It was added at link time by the /STUB linker argument. I can't find any documentation (apart from vague references to statements like ".NET will contain a win32 stub...") on how to do this - or even if such a thing is possible!
I think the difference here is that just because you are running in a dos shell the windows operating system was still installed. In this case we are taking about something that is not installed. There are three core dlls that run the .net framework. Without these a .net app will not run.
Last Visit: 31-Dec-99 18:00 Last Update: 24-Jun-21 6:36