|
Abisodun wrote: I thought were clear - You meant no instance variable of the class as opposed to an instance declared local to the method.
Exactly. 
|
|
|
|
|
Your statement's been bugging me now I realize why. This code will cause a compilation error:
class MyClass
{
internal string stringVariable = string.Empty;
internal static void MyFunction()
{
stringVariable += "a";
}
}
Did you mean static variable of the class?
Instance variable always refers to a non static variable.
i.e.
class MyClass
{
internal string stringVariable = string.Empty;
internal static void MyFunction()
{
MyClass myClass = new MyClass();
myClass.stringVariable += "a";
}
}
which should not be a problem in a static method of the same class.
|
|
|
|
|
Abisodun wrote: Did you mean static variable of the class?
Instance variable always refers to a non static variable.
Yeah, I should have just said that since the methods are static, it's thread safe. I confused the issue by mentioning instance objects. The instance variables of a class can't be accessed from a static method, so there was no need to bring them into the discussion.
The main thing to watch out for with static methods and thread safety are objects that are passed into the method. Something like this:
public static void DoSomething(SomeObject obj)
{
obj.Change();
}
This isn't tread safe. The reason being that two threads could call this method at the same time (relatively speaking), and the "Change" method may be performing some thread unsafe operation. The example you gave in your original post didn't do this, so it's thread safe. But also, if an object is a class level variable, you still want to be careful:
public class MyClass
{
private static SomeObject obj = new SomeObject();
public static void DoSomething()
{
obj.Change();
}
}
This isn't thread safe for the same reason the first example isn't thread safe.
In your original post, all of the objects that were used were created within the static method. This means that if two threads called the method at the same time, the objects each thread uses is unique to the thread. So your original example is thread safe.
Does this help? Hopefully, I haven't made it more confusing.
|
|
|
|
|
No it's been very helpful. I was really only concerned about "List<string> list" being passed between static methods and recursively. But each new call stack starting with GetList in the first example should have it's own instance of "List<string> list".
I appreciate your help.
|
|
|
|
|
Hey All,
I'm trying to update a database using .Net remoting. I am using SQL server code that includes variables like the following: @StudentFirstName.
When I run the program and hit the update button, which contains the following code:
this.dgResults.DataSource = dbc.ExecuteQuery("UPDATE Student SET FirstName=@StudentFirstName,LastName=@StudentLastName,Address=@StudentAddress,Phone=@StudentPhone,GPA=@StudentGPA WHERE StudentID = @StudentID AND FirstName=@OriginalFirstName AND LastName=@OriginalLastName AND Address=@OriginalAddress AND Phone=@OriginalPhone AND GPA=@OriginalGPA");
dgResults.DataMember = "Results";
I get an error saying that @StudentFirstName must be declared. I am wondering how you declare @StudentFirstName in C# using .Net Remoting. Anyone got any ideas or answers?
|
|
|
|
|
Since you are passing in a string into your ExecuteQuery, you really need the actual values that you want to update your student table with. So if you have parameters getting passed into this method say:
p_studentFirstName,
p_studentLastName,
p_studentAddress ...
Then your update would be:
this.dgResults.DataSource = dbc.ExecuteQuery("UPDATE Student SET FirstName="+p_studentFirstName+",LastName="+p_studentLastName+",Address="+p_studentAddress+...
Anyway, hope that helps.
Ben
|
|
|
|
|
I would like to hear about intellectual property protection issues experienced by .Net commercial product developers and users of commercial 3rd party products protected by applications such as .NET Reactor:
http://www.eziriz.com/[^]
I want impervious intellectual property protection and a perfect user experience. Can do?
|
|
|
|
|
|
Thanks so much, Glen.
Glen Harvy wrote: I have had one user try to run a .Net Reactor program compiled with the All CPU flag enabled on a 64 bit XP system without any luck. Eziriz said it should work on 64 bit as a 32 bit program but it apparently doesn't.
Is it possible they have some level (.Net configuration, OS configuration, etc.) configured to run 64-bit only?
Glen Harvy wrote: If someone can get to my code after it has been through .Net Reactor then I should feel flattered that they have gone to the trouble of doing so
Perhaps. But (unas Dylan said it) *if* "we have something to protect," it needs to be the other way around -- truly undefeatable.
The issue I have at the moment is with custom licensing, and handling the licensing scheme. I just don't find much information in the documentation as to custom features... handling additional fields... that sort of thing. Do you use the SDK for such purposes?
Glen Harvy wrote: One funny thing though - when you use .Net Reactor I found that it seemed "to easy" to use and so fast compared to the others. A bit like "Surely it can't be that easy"
That's a pretty strong recommendation. I tried the trial issue and built a distributable in little time, but am left with some stupid questions. What is a bona fide test system, and how should we go about testing so as to determine everything is working as it should? What does the user have to do on their end to process the license?
In other words, what I am wanting to do is collect the CurrentUser name and email address to which the validated will be returned, and to process that in validation process. Does the user have to manually run HID.exe or what? I mean, is it just a matter of determining that HID.exe has to go and remain with your distributables?
Another issue is how much performance might be degraded (if at all), compared to obsfucation? There might not be much difference there, but if there is, I'd like to know about it.
|
|
|
|
|
mike montagne wrote: The issue I have at the moment is with custom licensing, and handling the licensing scheme. I just don't find much information in the documentation as to custom features... handling additional fields... that sort of thing. Do you use the SDK for such purposes?
I am using 2.7.1.5 and have just visited their site and notice the newer version - which I shall look at shortly.
I agree - the documentation is poor and frankly after reading a fair bit of their competitor's help/manuals it left me wondering if their program would do what it claimed. If you boil it all down though, their competitors help/manuals need to be considerably thicker because they allow far more options/fine tuning. Having said that, that is also why their competitors programs take so much longer.
I tested out the licencing part of the package AFTER I had already incorporated my own into my program. I figured that providing my program couldn't be de-compiled then that was sufficient for me to use my own method of key generation/validation. I looked at the licencing SDK but didn't use it for that reason. My program is one that probably wouldn't be used by a "hacker", reports are hard-coded etc so that was good enough for me.
mike montagne wrote: That's a pretty strong recommendation.
It is and I mean it  . Adding .dll's is easy and cuts down on distribution. As far as scrambling my code is concerned it's a breeze. I don't need all the bells and whistles and I don't need to convince a boss that loves to see confusing screens, multilayed and configurable levels, pick and chose which strings to obfuscate etc.
I don't think you can customise the licencing side of it very well at all (at least I didn't think so). It was/is one of the reasons I don't use their licencing module. I also don't like linking my program to a computer (and this may detract from your product sales). Having said that, geting a user to use HID.exe shouldn't be a problem. HID just identifies some hardware components and creates a code based on that hardware. HID is not used again unless the user makes a hardware change. I believe .Net Reactor checks the hardware itself and compares the supplied code if you have configured it to use hardware checking.
You shouldn't be issuing a key until after they have paid so running HID.exe and sending you the resultant code shouldn't be a problem. I haven't tried it but you could include HID in your distributable and have your own program run it and send you the code without any difficulty.
Performance should not be an issue at all. There must be some degredation but I haven't had any adverse comments nor have I noticed any degredation - except of course a minor unnoticable (to the user)delay at startup. It's so minor I couldn't really bother to measure it.
I'll have a look at Version 3 and let you know if I have any other comments to make.
Another point about the licencing module is you should check with whoever is going to collect the funds/issue the keys as to their requirements. If your doing it yourself then no worries .
Let me know how you go - your the first person I know of that's actually using (or at least thinking) of using it. I have searched the net high and low for feedback etc without any luck.
Regards,
Glen Harvy
|
|
|
|
|
Wow. Thanks so much for so much to think about!
Glen Harvy wrote: If you boil it all down though, their competitors help/manuals need to be considerably thicker because they allow far more options/fine tuning.
I think my needs are like yours. The intellectual property protection is a must have issue -- and the decision comes down to whether or not it will be cracked by people who will damage my market.
Glen Harvy wrote: I also don't like linking my program to a computer (and this may detract from your product sales).
I'm interested in your thinking here. What I want to do is offer a basic license, with extra (multiple installations) extensions costing enough to cover processing costs with a small profit. In other words, a $50 product with $15 multiple installation extensions.
In my experience, people don't pay for things if they don't have to. But like you say, if *I* buy software, I want to be able to install it on multiple systems. Sometimes I'll take it with me. Most of the time I'll work on it at the office. My hope is to make those further installations formal, yet not an abuse of the client (like so many licenses are).
As to .NET Reactor, I'm waiting to hear back from Denis there. I haven't tried to decompile yet, but I am about to do that. I just finished testing of the output .dll (my product is a library), and it went fine, although, like you, I didn't test 64-bit (which may prove to be an issue).
I really don't know what's supposed to be functional in the trial version. Everything appears to be working fine as far as reproduced CIL is concerned. Not even a detectable slowdown. That's very good. However, in my NR project, I have set an Inbuild Evaluation period (15) and Inbuild Number of Uses (50), with Show Expiration Screen, Show Nag Screen, and Shutdown Process after Expiration all set to true. Yet whether I copy the output license file to my test directory or not, I'm not seeing an Expiration or Nag screen, nor is my process shut down without the license. That doesn't bode well, but I'm waiting on an answer as to whether that is supposed to work in the demo installation. He *did* write me earlier that I *would* be able to test locally -- whether that means these features are not enforced I don't know.
I don't know why he has the separate Lock Settings and License Manager tab. I had to manually set the License Manager tab information to match the Lock Settings information -- which was simply ignored (?).
I like to see these kinds of (simple) things work perfectly. I may still use the product (even anxiously), but it may end up being with the same caveats you have raised. I've asked a number of questions about custom licensing and the SDK. I just don't have those yet -- and like you probably, I hope to avoid programming down any dead ends there.
In the past, in Windows executables, I have used a licensing scheme which marks the system and which is practically tamper proof (efforts far exceed the potential benefits). That was custom coded.
You don't happen to know of any material/guidelines for doing that with .NET libraries do you? The issues are somewhat different, and it would be nice to have a launching point from which to custom develop my own system, versus relying on the NR SDK for that.
tia,
m
|
|
|
|
|
|
Similarly, I studied .NET licensing classes last night, and it's not really clear just how I'll want to go about writing a licensing scheme -- whether to use file I/O classes.
From what I see in the .Net SDK documentation, our license must be marked with a *.LIC extension.
The name of the file must be the fully qualified name, including the namespace, of the class with the file name extension .LIC. For example:<br />
<br />
Namespace1.Class1.LIC
This is not the case for the NR license (.license), so the NR system must be proprietary. That's OK with me -- it may be a much better thing to do, because I find the VS .Net SDK documentation quite ambiguous too. For instance,
The content of the license file should contain the following text string:<br />
<br />
"myClassName is a licensed component."<br />
<br />
myClassName is the fully qualified name of the class. For example:<br />
<br />
"Namespace1.Class1 is a licensed component."
Personally, I read this stuff and ask myself what it can mean to anyone. I want to know how this string, "Namespace1.Class1 is a licensed component." is processed. You would suppose that if it is removed or altered that this invalidates the license, but how and why -- and what alternate processes take over then? By the time you have deciphered all the cryptic documentation an unexplained issues (by costly experimentation), you can have far too much time in a small bit of functionality. A crux of the design issues is splitting the design time behavior and runtime behavior of distributables. The documentation seems to suggest this happens, but not how. You return a validation value by overriding a method.
Unfortunately, I don't see the path as being very clear here either. Like you, I most appreciate the fact that the NR licensing scheme will be hidden by a process beyond obsfucation -- and that is presently the deciding factor in the fork I'm going to take here, especially as I have now heard from Denis, and he's agreed to let me help him improve NR's documentation. My thinking is that I'll get my job done faster with more direct help, and that if we can improve the documentation, it may be very clear what to do with what my intuition tells me is the most promising way to distribute commercial .Net assemblies which require (or benefit from) intellectual property protection.
I'll read your other posts now, but will report back in the next few days if I can, on what progress Denis and I have made with his documentation. This should be interesting.
m
|
|
|
|
|
You should move this topic to a new Subject and see if anyone else can help you as well.
I didn't know that there was a licencing method in the .Net SDK until you mentioned it. I wrote all my own code which, being obfuscated is good enough for my program and it's target market.
I did find this interesting [^] which may assist you. There may even be sources available to you on codeproject!
Good luck.
Glen Harvy
|
|
|
|
|
Denis and I are working on this together now, but I'll look at your link in a second here.
|
|
|
|
|
Hey, great article. He says, "While I believe that for completeness I should describe how you use LicFileLicenseProvider, I also believe that anyone serious about licensing their software will most likely avoid such a simple scheme in favor of their own, more creative schemes, one of which I'll introduce to you after describing LicFileLicenseProvider."
I was pretty quickly convinced of as much last night as I explored the "documentation."
THANKS A BUNCH!
|
|
|
|
|
Denis and I are hashing out some ideas about licensing. Hopefully we will come up with a boilerplate which will solve issues right out of the box.
|
|
|
|
|
Ouch. I haven't even done this before (ILDASM), and (I'm wondering if I have my head up my hind), but I'd certainly tend to assume that I'm looking at my source as CIL.
?
.method family hidebysig instance valuetype [System.Drawing]System.Drawing.Color
Color_IncOrDecLum(valuetype [System.Drawing]System.Drawing.Color C,
int32 LumDif) cil managed
{
// Code size 85 (0x55)
.maxstack 14
IL_0000: ldarga C
IL_0004: call instance bool [System.Drawing]System.Drawing.Color::get_IsEmpty()
IL_0009: brtrue IL_0053
IL_000e: ldarg.2
IL_000f: brfalse IL_0053
IL_0014: ldarga C
IL_0018: call instance uint8 [System.Drawing]System.Drawing.Color::get_A()
IL_001d: ldarga C
IL_0021: call instance uint8 [System.Drawing]System.Drawing.Color::get_R()
IL_0026: ldarg.2
IL_0027: add
IL_0028: call int32 ADVANCEIS.Controls_N.GCServer_Base::RectifyTo_0_255(int32)
IL_002d: ldarga C
IL_0031: call instance uint8 [System.Drawing]System.Drawing.Color::get_G()
IL_0036: ldarg.2
IL_0037: add
IL_0038: call int32 ADVANCEIS.Controls_N.GCServer_Base::RectifyTo_0_255(int32)
IL_003d: ldarga C
IL_0041: call instance uint8 [System.Drawing]System.Drawing.Color::get_B()
IL_0046: ldarg.2
IL_0047: add
IL_0048: call int32 ADVANCEIS.Controls_N.GCServer_Base::RectifyTo_0_255(int32)
IL_004d: call valuetype [System.Drawing]System.Drawing.Color [System.Drawing]System.Drawing.Color::FromArgb(int32,
int32,
int32,
int32)
IL_0052: ret
IL_0053: ldarg.1
IL_0054: ret
} // end of method GCServer_Base::Color_IncOrDecLum
|
|
|
|
|
I've run it all a few more times.
Step 1 [Examining] :
Successful
Step 2 [Protection Layer 1] :
Successful
Step 3 [Protection Layer 2] :
Information: DEMO MODE! Obfuscation(50%).
Successful
Step 4 [Resign Assembly] :
Successful
.NET Assembly Successfully Protected
New Protected Version Of Your .NET Assembly Created In:
C:\VS2005\N\GC\obj\Release\GCControls_N_Secure\GCControls_N.dll
As to what this means... "Information: DEMO MODE! Obfuscation(50%)."... I do not know.
This is not looking good. It's like all settings are ignored in trial mode, or... ehem. Have you looked at your output with ILDasm? I'm getting the same thing every time -- readable IL, not even obsfucated.
|
|
|
|
|
Send me your test program and I'll NR it for you.
I thought the demo output was pretty descriptive - it only obfuscated half your code.
Xenocode only obfuscates 10% of the code and only hides 50% of strings in demo mode.
Glen Harvy
|
|
|
|
|
No can send the demo, but I sure do appreciate the offer. I can't get a rise out of Denis. I surely would like to know what's going on here. I have the settings tweaked that should be protecting output. I would think NR would like to show that off in demo mode. This stuff is simple. It shouldn't be a big deal.
|
|
|
|
|
I dunno where you are but Denis probably isn't even at work yet - he is in Germany.
I don't want to do their technical support but if you send me the .nrpoj file I can glance over that and see if there are any obvious setup problems.
Cheers,
Glen Harvy
|
|
|
|
|
I think my first mail should have caught him.
Thanks again for the offer again. Maybe you might want to do a little beta *installation* testing for a free license when I get this rolling? That should be more fun.
Just for the heck of it I looked things over again and decided to turn Compact Framework compatibility off. (I guess I was stupid to think the option meant extended versatility.)
So now when I protect, I get this (different) message string:
Step 1 [Examining] :
Successful
Step 2 [Protection Layer 1] :
Successful
Step 3 [Protection Layer 2] :
Successful
Step 4 [Resign Assembly] :
Successful
.NET Assembly Successfully Protected
New Protected Version Of Your .NET Assembly Created In:
C:\VS2005\N\GC\obj\Release\GCControls_N_Secure\GCControls_N.dll
Please Only Ship Your Protected Assembly Together With 'GCControls_N_nat.dll'
-----
What do you know. That's the first I saw a *nat.dll, and *nat.dll cannot be disassembled. Nor does my GCControls_N.dll seem to have but a little information in it now -- and not much at that.
I don't know what to make of the resource multiplication yet. We have grown from a 60K library to two libraries, one being 67K and the other (*nat.dll) being a whopping 212. Ouch. I expect that means ultimate distributables will be bloated that much.
I am a happier camper however with the arfie dog part barking.
Researching what I can do with a license scheme. I think the cleanest thing will be to do as you have -- write your own.
|
|
|
|
|
There ya go - it worked.
I have compression turned on and the .exe that I distribute is 791k verses about 1.8 meg for the executable and three included dll's.
Glen Harvy
|
|
|
|
|
Wow. Pretty interesting content in *nat.dll, including a string, "This program must be run under Win32"
I wonder if that has anything to do with the 64-bit behavior. In any case, some of the widely spaced strings have me wondering what I'm looking at here (in Notepad). Have you looked at this stuff?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
.