|
|
Finally I found a solution to the ever irritating problem of bi-directional relations between objects that are saved in a database. Ok, the solution wasn't really obvious and rather complicated if you ask me:
queryBuilder.Append("SELECT Computers.Computernummer,");
queryBuilder.Append("Computers.X,Computers.Y,Computers.Geblokkeerd,");
queryBuilder.Append("Leerlingen.Leerlingnummer,Leerlingen.Naam,");
queryBuilder.Append("Leerlingen.Klas,Leerlingen.Foto,");
queryBuilder.Append("Leerlingen.Geblokkeerd as LeerlingGeblokkeerd");
queryBuilder.Append(" FROM Computers LEFT OUTER JOIN ");
queryBuilder.Append(" Leerlingen ON Computers.Leerlingnummer");
queryBuilder.Append(" = Leerlingen.Leerlingnummer");
while (reader.Read())
{
Computer computer = new Computer();
...
if (!reader.IsDBNull(4))
{
Leerling leerling = new Leerling();
...
computer.Leerling = leerling;
leerling.Computer = computer;
}
...
In short, what I do here, I select a computer and possibly with it a student. This only happens when the student has been logged on to the computer. Sounds simple, code looks complicated.. And it took me quite some time to figure it out.
Maybe this tip can be good for others which have the same problem.
WM.
What about weapons of mass-construction?
|
|
|
|
|
Can anyone tell me what are the C#, ASP.NET coding standards followed in the industry ?
Cheers,
Tabarak
|
|
|
|
|
|
|
The product I work on is in C#, and we're talking about making the code harder to reflect/steal. I heard NGen does a precompile, but the docs seem to imply this is done per machine, not to make an exe to distribute. Is that right ? Is the obsfucator worth looking in to ? Or should I tell the guy to fund a rewrite in C++ ? :P
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
That is a definition for it : Go[^].
And also this may help :Here[^].
|
|
|
|
|
NGen generates code per processor, not machine. Even some of the processor revisions are considered when it gen's code.
I'd look into the obfuscators. Nothing is going to prevent a determined schmuck from reversing the code, but then again, they could do the same to C++ source too.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Dave Kreskowiak wrote:
NGen generates code per processor, not machine. Even some of the processor revisions are considered when it gen's code.
So I can end up with an exe I can ship ?
Dave Kreskowiak wrote:
I'd look into the obfuscators. Nothing is going to prevent a determined schmuck from reversing the code, but then again, they could do the same to C++ source too.
Yeah, you can never stop it, but I want to be able to tell the client I've done what we can.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
I am facing a similar dilemma.
But, one thing is clear, ngen.exe is NOT the solution for this purpose due to following reasons:
1. The image created by it on a particular machine / processor may not work on another one.
2. Even the idea of creating an image by using ngen.exe on the client machine itself at the time of every such installation may not work for the simple reason that your "real" assembly is still required to be in place in its application directory for the reason "in case it is required in future". So what you have is like this: while your application in the ngen cache will be in the native code (leading to some source-code protection), your assembly is still available in your application directory for eveyone to see its source code through disassembers like ILDASM or Reflector. The reason for the "real" assembly's presence is that the subsequent changes made in the system, etc., may make the native image created through the ngen.exe a useless file, thereby again requiring the "real" assembly. This is as adviced in the documentation itself.
3. Moreover, as per documentation, the basic purpose of ngen.exe is to create a native image for faster run-time experience (to avoid the Just-in-time compilation). The basic purpose of ngen.exe is NOT to make the source code protected from the prying eyes; it is just a limited by-product of the native image.
Obfuscation is also of limited utility, because it may hide names of your user-defined symbols (fields, methods etc.), but the in-built library names / symbols are still for everyone to see, which is more than sufficient for a good programmer to get enough clues. A good obfuscator may help even to prevent decomilation to some extent, but disassembly is more or less not prevented to the extent required.
One does not know how far a solution such as Salamander's .NET Protector would protect the source code, though they claim that the source code is not disassembled if their product is used.
Apparently, this is the biggest drawback of .NET.
When Dave says that even C++ code is not fully safe, perhaps he is right. But, then it is a question of "scale". In C#, what can be seen is your complete class structure with full details which even a naive programmer can understand. But, in C++, what you can disassemble is only non-transparent "sequential" assembly-language code, which is not easy for everybody to decipher. One may still say that a good programmer may not even have to look into your source-code, he may simply re-create a replica of your application just by looking at its features. But, I hope we are trying to keep our source-code safe from "most" people. Absolute is never possible. Optimazation (and relative) is the answer.
Regards
|
|
|
|
|
Yeah! What he said!
I don't have time to type something as long as Ashok.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
I had also thought on similar lines. But, the problem areas in this approach could possibly be:
1. When ultimately the assembly is decompressed and decrypted just before its actual execution, it will either be in the form of a temp file (or may some other form of a physical file) or may be in the byte stream form. At that time, it is in its raw / source code form, and so if copied from there, it is exposed to the same risk.
2. Memory-dump at the time of the execution.
So, perhaps some further refinements may be required.
However, to be fair, something is better than nothing. Such a method can definitely keep it secret from "most" people if not all, and that is what should perhaps be the goal too.
|
|
|
|
|
|
|
I want to encapsulate the webbrowser even further than it already is. The reason is that I have tons of functions that operates on AxWebBrowser, so it would be logic to make these member functions of the AxWebBrowser class.
I always needs to load the same html page, so I do this in a member override:
protected override void CreateSink()
{
base.CreateSink ();
object empty = System.Reflection.Missing.Value;
this.NavigateComplete2 += new AxSHDocVw.DWebBrowserEvents2_NavigateComplete2EventHandler(VETViewer_NavigateComplete2);
this.Navigate("page.html", ref empty, ref empty, ref empty, ref empty);
}
What I am interested in is calling my functions like this:
public Form1()
{
InitializeComponent();
this.axWebBrowser1.Function1(); // This causes an error, since the navigateComplete2 event has not yet arrived
}
My problem is that I MUST NOT CALL ANY OF MY MEMBER FUNCTIONS before the NavigateComplete2 event has been fired.
I first thought the event would be fired on a different thread (so i could do thread synchronization), but that is NOT the case. It looks like the webbrowser waits for a navigatecomplete2 complete message, which will be called loooong time after Form1 has been completed. What can I do here?
Gooky
|
|
|
|
|
New to C# here... Just wondering if there are any network libraries out there (or built-in) that allows the programmers to display IP address, MAC address, and other network information in a user-friendly window?
Any help would be appreciated!
-ap
|
|
|
|
|
|
Im having problems with an area of my form wich is transparent not invalidating properly if i have a control in that area then remove or move it an image of it is left behind has anyone got a surgestion?
|
|
|
|
|
Try this.Refresh(); after moving.
Or this.Invalidate(); .
|
|
|
|
|
ive tryed both i dont thinks its a problem in the invalidating itself more in the fact it dosnt invalidate the transparent areas
|
|
|
|
|
Try :
this.SetStyle(System.Windows.Forms.ControlStyles.SupportsTransparentBackColor | System.Windows.Forms.ControlStyles.Opaque);
.
|
|
|
|
|
opaque makes the middel of my form go transparent setting the backgruond to trasparent with supports transparent it gives me a cream background and my form flickers (even with doublebuffer)
|
|
|
|
|
I have noticed that Visual Studio .Net 2003 enjoys automatically adding dependencies to the setup project that cause the build to fail unless they are excluded. (ex. msado27.tlb, msado26.tlb, activeds.tlb, etc.) I am trying to build a large number of applications at once using a script which is not a problem when testing the script on my machine since it is the development machine and I have already excluded the "bad" files. The problem pops up when I try to build the applications on a different machine where Visual Studio believes that it should add different dependencies and therefore fail during the building of the setup project.
I have yet to see the use of requiring a file that must be excluded.
Is there anyway to exclude files before they show up as dependencies? Like a list of files that if they show up, they are excluded? Or maybe a filter of some sort.... "Don't include *.tlb" :Hopeful:
Thanks
-J
Think of a computer program. Somewhere, there is one key instruction, and everything else is just functions calling themselves, or brackets billowing out endlessly through an infinite address space. What happens when the brackets collapse? Where's the final 'end if'? Is any of this making sense?
-Ford Prefect
|
|
|
|
|
I personally stopped using VS.NET 2003 for Setup Project. I took the time to write one batch installer, which is included with my ZIP-file and will install the directory to any location desired and make changes to the registry.
If you are not programming for profit, you might want to look into Nullsoft Installer or other "free for non-commercial use"-setup tools, which usually wield a much bigger palette of tools than the castrated "Windows Install Maker" included with VS.NET 2003
Cheers,
Sebastian
--
Contra vim mortem non est medicamen in hortem.
|
|
|
|
|
I appreciate the answer, but changing our installer is, unfortunately, not something we can do.
Thanks
-J
Think of a computer program. Somewhere, there is one key instruction, and everything else is just functions calling themselves, or brackets billowing out endlessly through an infinite address space. What happens when the brackets collapse? Where's the final 'end if'? Is any of this making sense?
-Ford Prefect
|
|
|
|
|