.NET (Core and Framework)

next dot.net application error

15-Jul-03 8:55

Actually, if this happened when you're running the application, more than likely the .NET Framework is either not installed or not installed correctly. If an exception occured in the .NET application itself, the message would be different. This is Windows's default Dr. Watson (or whatever name they give it these days) message. Basically, the VC runtime doesn't understand the PE/COFF executable format. These formats have references to the VM that runs them, like VB (non-.NET) and .NET assemblies.

Also, remember that the language doesn't matter, except in the case of certain language interoperability issues (NOTE: not COM interop - just language interop). MC++ has some language-specific assemblies to allow developers to use mixed mode and some C++ symantecs. VB.NET has a few assemblies that allow developers to use the "old ways" in some cases. These assemblies basically have some methods that older code uses wrapped into an assembly. Other than that, all .NET languages compile to intermediate language, or IL, which doesn't have anything to do with the source language. Just FYI.

Reminiscent of my younger years...

LOAD "SCISSORS"

RUN

misiek16-Jul-03 6:20

misiek

16-Jul-03 6:20

To test if any application can work in (the mentioned above) .Net Framework environment, I wrote a small application (just a form with one button) with exception handling in Main() function.
This application is not working either and the message (exception message) is:
"System.Arithemtic.Exception: Overflow or underflow in the arithmitic operation.
at System.Drawing.Font.Initialize(FontFamily family, Single emSize, FontStyle style, GraphicsUnit unit, Byte gdiCharSet, Boolean gdiVerticalFont)
at System.Drawing.Font..ctor(String familyName, Single emSize, FontStyle style, GraphicsUnit unit, Byte gdiCharSet)
at Test15072003.Form1.InitializeComponent()
at Test15072003.Form1..ctor()
at Test15072003.Form1.Main()"

So what kind of problem it might be (.Net Framework)?
Thanks for help in advance.

misiek

Garbage Collection in DotNet

dskumar9914-Jul-03 4:24

dskumar99

14-Jul-03 4:24

Hi

I have converted FOP(Java) application to J# (DotNet) after converting iam facing memory problem.Memory is keep on increasing finally Virtual memory error is coming in DotNet version but not in Java.

Any suggestions?

SivaKumar

SivaKumar

Re: Garbage Collection in DotNet

Philip Fitzsimons15-Jul-03 2:32

Philip Fitzsimons

15-Jul-03 2:32

GC.Collect();

"When the only tool you have is a hammer, a sore thumb you will have."

Re: Garbage Collection in DotNet

Heath Stewart15-Jul-03 8:58

Socket Problems on particular machine

15-Jul-03 8:58

Besides calling GC.Collection(), you might be holding on to references in objects. As long as there is a reference to an object held somewhere in your app / library, the object is in memory. While GC.Collect() forces garbage collection, it won't help if you're still holding object references. It'd be a good idea to check your code over.

Reminiscent of my younger years...

LOAD "SCISSORS"

RUN

stonee7413-Jul-03 5:43

stonee74

13-Jul-03 5:43

Hello There,

I am looking for a solution of this problem now for weeks.
I am using VS .NET 2003 on Windows2000 SP3.
I am programming in C#.

Creating an instance of a Socket

//Socket Instance<br />
m_socket = new Socket <br />
    (AddressFamily.InterNetwork,<br />
    SocketType.Stream,<br />
    ProtocolType.Tcp);

results in the following message:

An unhandled exception of type 'System.Net.Sockets.SocketException' occurred in system.dll

Additional information: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full

I have researched on the internet but found no useful information yet.
I do not want to connect to a host higher than 5000, and I have 3NIC's installed on my machine.

Any help is greatly appreciated.

regards,
stonee

Re: Socket Problems on particular machine

stonee7428-Jul-03 4:49

stonee74

28-Jul-03 4:49

any ideas?
thanks...
stonee

Another "Interop" question.

igor196012-Jul-03 12:46

12-Jul-03 12:46

The more I work on my original idea and deeper into .NET Interop -- the more I'm confused. Maybe somebody could explain to me.
Here is the scenario:
1. Suppose I want to automatically export my Assembly to TypeLibrary, so other possible COM clients could use it;
2. I'm doing the following: from inside of assembly I'm using TypeLib Converter like that:

TypeLibConverter converter = new TypeLibConverter();
ConversionEventHandler eventHandler = new ConversionEventHandler();
UCOMICreateITypeLib typeLib = (UCOMICreateITypeLib)converter.ConvertAssemblyToTypeLib( GetExecutingAssembly(), TypeLibFileName, 0, eventHandler );
typeLib.SetName("SomeLib");
typeLib.SaveAllChanges();

Everything works as expected and TypeLibFileName after has all interfaces, coclasses and etc.

The problem is: all types in created typelibrary that are not of Primitive Types, except System.String were changed, either to become smaller in length(example: System.Drawing.Size is now just Size) or got converted, so they don't contain "." (like System.Drawing.Point is now System_Drawing_Point).
However, some of CLR types were converted to COM types, like System.Windows.Forms.Form was changed to IUnknown*.

And here I'm completely confused:
What get's converted and what is not?
How changed names ("." - "_") are supposed to be found in refferenced type libaries?
How you suppose to use those TLB files in your UNMANAGED projects if they are not complete -- by not complete I mean: there is no chance System_Drawing_Point could be found in refferenced typelibs (or maybe I'm wrong)?
Is there anyway of changing that behavior?

Maybe I don't understand some main principles here. Maybe Idea of typelib exporting is designed just for types you manually defined and therefore they are already COM complient. Or each of defualt Object types should be wrapped before being able to use it from COM? I thought that default dynamic CCW could be created for any Object derived .NET type -- and if so it's just typelib restriction or grammar errors i'm facing? But then, why "." was selected as name/class divider by .NET team if it's in conflict with typelib grammar?

Again, waiting for some help here...

igor196012-Jul-03 15:23

12-Jul-03 15:23

OK, looks like I figured that out. Not elegant, but before automatically creating typelibrary, if I create a wrapper around original .NET component, enumerate all properties/methods/events and compile this wrapper -- then I could create TypeLibrary of that wrapper, which will corresponds to TypeLibrary of original object... While creating that wrapper I'm only placing alowed automation properties/methods/events in it -- so my code looks like that for methods:

foreach(MethodInfo mi in t.GetMethods())
{
ParameterInfo[] pi = mi.GetParameters();
Type type = mi.ReturnType;
string sType = type.ToString();

if(sType == "System.Void") // Could I determine Void without string comparison???
sType = "void";
if(sType != "void")
{
// I'm skipping here return types causing trouble:
if(!type.IsClass && !type.IsPrimitive && !type.IsInterface)
continue; // bad automation method
}
........
bool bExclude = false;
for(int i=0; i

Mike Dimmick13-Jul-03 1:16

Mike Dimmick

13-Jul-03 1:16

The TLBEXP tool is for exporting types from a .NET assembly to COM. You should use REGASM to register your assemblies for COM while you're developing (or tick the 'Register for COM Interop' box in the IDE), and select the appropriate option (which I currently forget) in the deployment project for the assembly.

The purpose of the type library is to allow COM clients to know what classes, interfaces, methods and other types the assembly exposes. This is used by scripting engines at run-time, and VB6 at design and compile time, and also run-time if you use the VB6 Object type.

The COM Callable Wrapper (CCW) is an object which the framework generates that looks like a COM object externally, with COM-compatible types. This is a stub translator which marshals the types from COM formats (e.g. BSTR) into .NET compatible types, then calls the .NET method.

To go the other way, for a .NET assembly to call a COM object, the runtime generates a Runtime Callable Wrapper (RCW). This is a proxy for the COM object which again translates types from .NET to COM-compatible formats.

Shameless plug: we've used this with our Meteor[^] product (a system for allowing thin-client hand-held data capture terminals to run an application on a Windows server) to allow development in VB.NET, while the server software itself is written in VB6. Most new applications we're writing are now in VB.NET.

--
Mike Dimmick

igor196013-Jul-03 9:25

13-Jul-03 9:25

So: what are you trying to say?
My complain and the problem was very specific: and exactly:
why not all CLR implemented and possibly exposed to scripting types are of Automation types?
For example: System.Drawing.Size is declared as struct -- therefore it cannot possibly participate in any functions calls through Automation either as a return value and/or argument -- therefore all CLR functions that use System.Drawing.Size will be visible to COM client, however will not be accesible through Automation (I mean IDispatch access)...
And it's not just Size: Have a look just in System.Drawing namespace:
Point, PointF, Rectangle, RectangleF, Size, SizeF... It's alot?

So, how in the world could you access them through "VB6 Object type" you are reffering?
Example: How you gonna call Control.Invalidate(Rectangle) from your script if Rectangle is not of automation type???...

Regards

Heath Stewart15-Jul-03 9:09

15-Jul-03 9:09

structs are valid in COM and are defined for IDL. As far as Automation goes, they can be used. The automation rules are rarely followed anymore and rarely need to be. Microsoft doesn't even follow them in many cases, as they've defined retvals that don't follow the rules, etc. You can, in fact, reference the TLB for System.Drawing.dll in VB6 and access the Size, Rectangle, etc., structures just fine.

Reminiscent of my younger years...

LOAD "SCISSORS"

RUN

Jeffster15-Jul-03 12:07

Jeffster

15-Jul-03 12:07

How can you Invoke a method on an IDispatch if the type is a structure or isn't an automation type? What is the vt param to describe this? My understanding is that these type of operations aren't possible through IDispatch and scripting.

Heath Stewart15-Jul-03 12:50

15-Jul-03 12:50

As I said, VB did it fine and the entire language is based on IDispatch. You don't use a VT enum because you don't use a VARIANT. You pass the struct back as the retval. It works fine. Most automation hosts don't care anymore and they work. Try it and find out for yourself.

Reminiscent of my younger years...

LOAD "SCISSORS"

RUN

igor196016-Jul-03 5:29

16-Jul-03 5:29

This is just one more demonstration that VB as well as .NET environment will allow you to forget the basics.
So you are saying you can access and pass structures solely through IDispatch? And "you don't use VT enum"? So, you can show me how to do that in a script, late binding, without TypeLibs?... Man -- what planet are you from?
"Most automation hosts don't care" -- that's really funny!
Me think you are mixing dual interface support with pure IDispatch...;P

Nick Parker13-Jul-03 9:57

Nick Parker

13-Jul-03 9:57

igor1960 wrote:
Again, waiting for some help here...

Try my article: Creating a RCW for COM enabled non .NET applications[^]

-Nick Parker

igor196013-Jul-03 10:52

13-Jul-03 10:52

Nick, your article is great. However, it's just not answering my specific question.
Thank you verym much.

WIN CE and .NET

Dato12-Jul-03 10:24

Dato

12-Jul-03 10:24

Do you need VS.NET 2003 to develop WINCE apps ? I can't seem to find a download for the initial VS.NET release ..

thks in advance.

Re: WIN CE and .NET

Heath Stewart15-Jul-03 9:16