.NET (Core and Framework)

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

15-Jul-03 9:16

No, you don't need VS.NET 2003. The Compact Framework was released along with VS.NET 2003 as merely a big marketing ploy. It was actually ready sometime before that from what I've heard. The beta works with VS.NET 2002 and the release works with VS.NET 2003. But, you don't need either of these IDEs to write applications for WinCE devices. The Compact Framework is downloadable separately and can be installed on the devices. You can install the .NET Framework 1.1 SDK and write applications without the IDE (good test of if you know the framework or just the IDE). The apps can be installed on the devices using tools in the WinCE 3.0 and 4.0 SDKs, and you can also build the CAB files manually using tools that are available in the Platform SDK (some tools installed by default along with VS.NET - including cabarc.exe).

IDEs are really only for RAD and are helpful, but never necessary.

Reminiscent of my younger years...

LOAD "SCISSORS"

RUN

Speech SDK question...

JoeSox11-Jul-03 7:43

JoeSox

11-Jul-03 7:43

does the .NET Speech SDK support parts of speech tagging?
if so what classes?
Thanks

Later,
JoeSox
www.humanaiproject.org
"Dream as if you'll live forever; live as if you'll die tomorrow."
- James Dean(ISTP)

Trial version

Anonymous11-Jul-03 3:51

Anonymous

11-Jul-03 3:51

I want to give a trial version of my software what is the best way of storing a variable to test the date of install, whether or not it was registered and an easy registration process, if anyone has an example I can look at I'd appreciate it. I dont want to use a file or registry setting that can be changed easily by a user.

Heath Stewart11-Jul-03 4:37

11-Jul-03 4:37

One thing I did with our software was to use an XML file with the computer's SID (unique to every computer) along with a timestamp and then sign the XML with our private key (kept secure, of course). The application can verify the XML signature (uses standard WS-Signatures from the Microsoft.Web.Security assembly since the ones in the .NET class library don't work in some cases) and compare the SID stored in the file with that of the computer's. If the signature is invalid, the user changed it and the app doesn't run. If the SIDs are different the computers are different and the app doesn't run. The timestamp tells you when it was installed and you can diff from the time from this. If the user modifies it, the app doesn't run.

You could further extend this by making that file the actual license so that you don't have multiple builds of your application. When the user purchases the license, they send you a raw XML file (timestamp and computer SID) that you add a value to which signifies that they bought it, then sign the XML and email it back to them (or use some sort of online system, which wouldn't be hard to develop).

Either way, if the file is modified, it is invalid.

Now, here's the trick. It's better to use an enveloped signature (the signature is part of the XML document) because it keeps your schema valid. You also shouldn't include the public key in the signature because if your app uses the public key provided, then someone else could change the values and resign the XML document with their information. If your app trusts the public key included, the user just pirated your software! So, make sure your app uses its own public key stored in its code (or uses the one that is part of its manifest if you sign the XML document and your assembly with the same key pair) and you're good to go!

Reminiscent of my younger years...

LOAD "SCISSORS"

RUN

Nick Parker12-Jul-03 4:59

Nick Parker

12-Jul-03 4:59

Heath,
Does your application consider issues with programs that can change the SID like NewSID[^]

-Nick Parker

Heath Stewart12-Jul-03 7:28

12-Jul-03 7:28

They would have to resubmit the license request file (basically, the unsigned XML file) and have it resigned and reissued. This is, however, similar to current public key cryptography. If you change your key, you must redistribute it and your old public key won't work anymore with the new private key. The computer's SID 1) isn't supposed to change unless you change domains, and 2) uniquely identifies the computer, just like your private key identifies you.

Speaking of domains, if you change the domain name in ActiveDirectory, the server certificates and everything the CA has signed is invalid. In public key cryptography, uniqueness is required somewhere so that you can verify signatures (basically, the encrypted hash).

I guess one could say that no content / application protection scheme is 100% effective and versatile. This one just uses standard cryptography practices that have been proven time and time again. It still isn't the best because of problems like you pointed out, but it'll work in most cases - a large most.

Besides, think of it like Microsoft activation thingy. If you change something major, you have to reactivate and probably will end up calling Microsoft. Your customers could have the same option where they explain the situation, so you can verify their credentials (perhaps a business ID or passphrase) and resign the file however you see fit.

Reminiscent of my younger years...

LOAD "SCISSORS"

RUN