|
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
|
|
|
|
|
No, not yet unfortunately. I just finished moving (though not unpacking) and have a deadline at work coming up soon. I do plan on writing bits of the article within the next couple of weeks, though, so stay tuned.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
I finally found some time to write the article: http://www.codeproject.com/dotnet/xmldsiglic.asp[^]
I hope this helps.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
|
Am I reading this right? A virtual machine just to manage application rights? How does it affect the program? I mean, it seems like it'd be effective, but not necessarily efficient.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
The virtual machine thing is mostly fluff.
What they basically do is embed a piece of code within your .exe. I believe someone posted a related article on Cp about doing such things.
Then, anytime you start the .exe it checks a license key somehow and, depending on the result, starts an internet-driven activation process. This process is meant to let/force users buy the software.
|
|
|
|
|
| There is a possible upcoming project at my place of employment that would require the .NET Framework to be installed onto client machines. Is there a way to push the framework to client machines from a Windows 2003 Server through an ASP.NET application?
Thanks In Advance.
Tony
|
|
|
|
|
Negative. What you could do is include a command in the user's startup script to run dotnetfx.exe from a server with the /silent switch (or something like that) and let them know to leave their desks for a few minutes.
Hawaian shirts and shorts work too in Summer.
People assume you're either a complete nut (in which case not a worthy target) or so damn good you don't need to worry about camouflage...
-Anna-Jayne Metcalfe on Paintballing
|
|
|
|
|
Thanks!
I will look into this through SMS also.
Tony
|
|
|
|
|
Actually, the .NET framework uses a Windows Installer file (MSI) with a separate CAB. If you use ActiveDirectory or have SMS server (which I saw that you do), you can certainly push it out to machines. Just don't use AD's Computer installation method because it only advertises information in the MSI and .NET's MSI has nothing to advertise!
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
As far as I know PInvoke just invokes a method in new unmanaged instance. Is it possible to pass the result from hosted object to the specific host instance that created hosted object without security problem?
|
|
|
|
|
I maybe missing something here, but to my knowledge: there is no such thing as "new unmanaged instance" -- there is just "unmanaged instance". Assuming that you are hosting CLR -- this is an instance. If this is true: then why can't you declare your unmanaged callback functions as exported. And now mark there prototypes in your managed portion as DllImported and call them.
Why this shouldn't work?
Now about "security problem"? As I understand, you are hosting managed code in unmanaged -- therefore, by defenition your application is not secured right from the beginning -- why would you want to enforce security in the middle of execution? Or maybe I'm missing something?...
|
|
|
|
|
Sorry for confusion, to simplify, please think about
applications such as asp.net. IIS probably hosting
those scripts, execute them in its hosted appdomain,
then get their output back to IIS.
I'd like to know how it works.
|
|
|
|
|
He's calling managed code from an unmanaged DLL. How would P/Invoking anything help? At the very least, the managed method he's calling would have to bind to a specific DLL which isn't very modular and is very restrictive.
To the original poster, have you tried creating an instance of a Delegate (it uses an AutoDual interface, which Microsoft always tells you not to use, BTW  ) Once you have an instance to that, you should be able to get what you need from there.
Just a thought.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
I'm seriously confused here.
From what I understand you have the following scenario:
1. Unmanage instance, lets name it (U) is hosting AppDomain and loads managed assembly, lets name it (M);
2. Now (U) calls some fuction or creates a clas or etc. inside of (M);
Original question was: how now (M) can call back fuction(s) inside of (U)?
My answer was:
what stopes you from declaring some entry points in (U) as Exported, through dllexport or .DEF file, and then declaring them in (M) using DllImport Attribute. If above is done, then you can call those entries from (M) directly into (U).
Maybe I didn't understand perfectly the scenario, but from what I understand: "He's NOT calling managed code from an unmanaged DLL", but opposite -- he wants to callback from managed into unmanaged host...
Regards,
Igor
|
|
|
|
|
Right, so he's going to P/Invoke a method from a specific DLL and use that in a managed method to emulate a callback. So, that DLL is the only DLL that can be used for a callback and no DLLs can be used instead. If that managed method isn't careful in its implementation, calling the P/Invoked method when the DLL isn't there could lead to problems like exceptions being thrown. It's restrictive, as I said, and is not modular at all.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
So, it "could be restrictive, not modualr and etc"... And I'm not arguing with that.
But, the main thing is: "He wants to CALLBACK from MANAGED to UNMANAGED" and therefore P/Invoke could help, which you originally dismissed!
Now, about "restrictive, not modular and etc": Sure if you implement managed callback through DllImport, you basically HARD CODED necessaty of having UNMANAGED Implementation loaded --> and that is why it's not flexible enough. However, that's exactly how P/Invoke works -- You are not questioning necessaty of user32.dll, gdi32.dll and etc. to support CLR OS calls...
Said that: there are ways of performing interpretive P/Invoke, but I thought it's out of the scope of original question.
Regards,
Igor
|
|
|
|
|
No, I get it - completely. P/Invoke could do it, yes, but it is RESTRICTIVE! He has to P/Invoke the unmanaged method in his managed code. Right there, that ties it to a specific DLL and that is the restrictive part. Then, in the managed code, he has to call that P/Invoke'd method. If he assumes that the method was found (i.e., the DLL exporting it is present) and, in fact, it wasn't found, the consequences could be bad if not handled right.
Trust me - I know how P/Invoke works. I get into the meat of .NET and have read all the documentation countless times. All I'm saying is that P/Invoke ties the code to one DLL.
Besides, you're also assuming that he has access to the source of the assembly. What if he's doing something in the .NET assemblies, part of the .NET framework. He can't add an external method and he can't make the message body call the P/Invoke'd method. A wrapper might be possible, but painful. My idea about instantiating a Delegate from unmanaged code (since it implements IDispatch, calling its methods are easy) and passing that to the callback parameter of whatever he's calling. He would still be to have a small assembly (or emit one) that receives the callback. Using your idea in that might work, but hard-coding it into the "target" assembly (if he can even change the assembly) isn't necessarily a good idea. If he can insure that these two assemblies will always be present together and that he doesn't want to ever replace the unmanaged DLL, sure it might work. Frankly, I just don't swing that way because I like to make my code versatile, instead of paying for it later.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
No question, I absolutely agree with you that the right and reusable way to do this would be to pass IDispatch supported object created in unmanaged part and put logical part of callback into it's Invoke method.
However, I thought, that original poster looks for "simple" and not bnecessarily reusable ways of achieving result. Said that: My feeling is that even with IDispatch solution: at some point you have the same P/Invoke, just implemented by RCW, isn't it? Yes, it would be dynamic, and yes you don't have to implement it. However, you have to inmplement COM objects on unmanaged site.
The only soultion I could think of that doesn't require P/Invoke at some point, would be probably: Creating WinSock port and start listening on it...hehehe
What is better and faster -- I don't know: depends on the project. I don't think that there is better/simplier soultion then just be able to callback as we were always doing in C, but unfortunately that's CLR restrictions.
About your point of making "code versatile" -- that is nice.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
