|
any ideas?
thanks...
stonee
|
|
|
|
|
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...
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
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.
|
|
|
|
|
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...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
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, your article is great. However, it's just not answering my specific question.
Thank you verym much.
|
|
|
|
|
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.
|
|
|
|
|
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...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
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)
|
|
|
|
|
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.
|
|
|
|
|
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...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
Heath,
Does your application consider issues with programs that can change the SID like NewSID[^]
-Nick Parker
|
|
|
|
|
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...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
What about using the MAC address of the computer instead of the SID?
-Nick Parker
|
|
|
|
|
That's a possibility, but if memory serves me correctly, that can be changed, too. Besides, isn't this on the NIC and not the computer as a whole? Swapping out the NIC - which happens much, much more often than changing the computer's SID - would render the license invalid.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
Heath Stewart wrote:
Besides, isn't this on the NIC and not the computer as a whole? Swapping out the NIC - which happens much, much more often than changing the computer's SID - would render the license invalid.
Good point, good conversation though. 
-Nick Parker
|
|
|
|
|
Is it worth posting an article to cover this topic (which you seem to know a lot about)? Myself and seemingly many other CPians would be interested to read the full story.
Derek Lakin.
Try the Code Store for instant integrated access to an online repository of .NET components.
I wish I was what I thought I was when I wished I was what I am.
Salamander Software Ltd.
|
|
|
|
|
Yeah, I could probably do that. It shouldn't take too much time and I've already got the code ready. In case I don't remember to post when I finish here, just keep an eye out for it. Probably'll be about a week since I'm pretty swamped at work.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
Great! I'll keep an eye out for it 
Derek Lakin.
Try the Code Store for instant integrated access to an online repository of .NET components.
I wish I was what I thought I was when I wished I was what I am.
Salamander Software Ltd.
|
|
|
|
|
Hi, I was wondering if you ever got to write the article about this? I am very interested and it sounds exactly like what i want. Even some sample code would be great
--Adam Turner
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
