|
C# and VB.net applications can easily be decompiled. Is there any way to protect the application made in .net from decompilation.
gold
|
|
|
|
|
there are obfustication tools available to hide your code. DotFusticator Community edition is bundled with Visual Studio. As wit all such tools, some are free, and will stop the casual code thief, after that you pay for what you get.
|
|
|
|
|
I don't know the specifics, as far as I remember VB6 runtime should be included with weven / 7 / windows vista whatever the hell it is now, but they have said it is a dead, unsupported language. Time to port to .net my friend.
|
|
|
|
|
EliottA wrote: whatever the hell
I like it 
|
|
|
|
|
VB6 is rubbish. Why on earth would you still be using it ? It's been a dead language for almost a decade.
Christian Graus
Driven to the arms of OSX by Vista.
Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
|
|
|
|
|
Christian Graus wrote: VB6 is rubbish
You've probably not used VB6 in your life.
|
|
|
|
|
Sadly, I have. And Microsoft agrees with me, that's why they killed it. VB.NET was going to be a lot LESS like VB6, before all the VB6 retards jumped up and down. They knew it was beyond redemption and set out to start again.
Christian Graus
Driven to the arms of OSX by Vista.
Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
|
|
|
|
|
Microsoft made a good decision to start everything from scratch. Apart from the basic language syntax, everything is different in VB.NET, adding to this was the unhelpful MSDN which made the transition for VB6 programmers a really tough one. That is why many programmers were reluctant to switch over to VB.NET (and consequently to .NET)
Despite all this, IMHO, I still feel that VB6 was not bad enough to be called "rubbish". If you consider pre-.NET era alone, you would appreciate why I made this point.
|
|
|
|
|
VB6 was only ever useful for people who wrote apps in a very narrow band, and for people who could make up the shortfall by using C++ COM dlls to do the real work.
Christian Graus
Driven to the arms of OSX by Vista.
Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
|
|
|
|
|
Shameel wrote: That is why many programmers were reluctant to switch over to VB.NET (and consequently to .NET)
No, not really. The switch was never made because businesses didn't want to spend the money on rewriting apps that were already written in VB6 and worked.
Shameel wrote: Despite all this, IMHO, I still feel that VB6 was not bad enough to be called "rubbish". If you consider pre-.NET era alone, you would appreciate why I made this point
Yeah, it's still garbage because it used error handling constructs that were 15 years old at the time, had very limited support OOP concepts, terrible interoperability support with native functions of Win32 and third party libraries, and limited support with everything else "Windows".
|
|
|
|
|
Yes, he has, as so have I. It is garbage compared to .NET.
|
|
|
|
|
Dave Kreskowiak wrote: It is garbage compared to .NET.
I wouldn't agree with you although I admit that it was a lot "less" than .NET that a comparison itself is not warranted.
But most people will agree with me that in the pre-.NET era, we did not have many choice as far as RAD tools were concerned.
|
|
|
|
|
Shameel wrote: But most people will agree with me that in the pre-.NET era, we did not have many choice as far as RAD tools were concerned.
Yes, pre .NET the basic choice was RAD or real programming.
Christian Graus
Driven to the arms of OSX by Vista.
Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
|
|
|
|
|
Oh, you mean C, C++, Delphi, PowerBuilder, Java, ...
|
|
|
|
|
|
So learn C++, what do you want, this is a choice you make when designing an application, not when already writing one.
|
|
|
|
|
So you really want to put up with poor contructs and design restrictions to gain code protection? That's all??
You don't have to protect your entire codebase in an application. You really only need to protect business logic and data access. The rest is just UI stuff that really doesn't need protection. If it's that damn critical, you've even have to obfuscate the VB6 code.
Face it, ANY code can be decompiled back to some form that is usable by a hacker. So what if they can't get the VB6 source back, they can still use a C equivilent that a decompiler can output of your VB6 app.
And yes, there are tools out there that will defeat .NET Reflector.
IMHO, what you gain from .NET greatly outweighs the "protection" you get when using VB6.
|
|
|
|
|
I have write following code for encrypt a file. But i don't know how to decrypt that file. Can anybody tell me how should i do that. I have declare a variable named k for store the key that used to encryption
Private k As Byte()
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
Dim infilename As String = "C:\aa.txt"
Dim outfilename As String = "C:\aa1.txt"
Dim infile As FileStream = New FileStream(infilename, FileMode.Open, FileAccess.Read)
Dim outfile As FileStream = New FileStream(outfilename, FileMode.OpenOrCreate, FileAccess.Write)
Dim malg As SymmetricAlgorithm = New RijndaelManaged
malg.GenerateKey()
k = malg.Key
Dim filedata(infile.Length - 1) As Byte
infile.Read(filedata, 0, CType(infile.Length, Integer))
Dim myenc As ICryptoTransform = malg.CreateEncryptor
Dim cryps As CryptoStream = New CryptoStream(outfile, myenc, CryptoStreamMode.Write)
cryps.Write(filedata, 0, filedata.Length)
cryps.Close()
infile.Close()
outfile.Close()
|
|
|
|
|
|
First, this is a repost. I received no answers from my previous query, and I feel it might have been due to my poor explanation of the scenario.
Scenario: I have made an MDI application. My main form has a flowlayoutpanel docked to the left (menu) and a panel docked to the top (header). My menu can be collapsed or expanded off a button click. The reason for this is to allow more content area (workspace) for forms that are loaded. As you know, the default backcolor for a MDI parent is a deep grey, which just looks horrible.
All this functionality works great. The last piece was having a background image on the workspace, which was simple enough. Set a BackgroundImage. This is done with the following code:
Me.BackgroundImage = CType(resources.GetObject("$this.BackgroundImage"), System.Drawing.Image)
Me.BackgroundImageLayout = System.Windows.Forms.ImageLayout.Stretch
Works fine, but when the menu is collapsed, the background image is not redrawn so there appears to be the same image twice by overlapping. The background image is redrawn perfectly when the main application is minimized then maximized, or you move a form over the entire working area that has a backgroundimage and it is magically repainted.
Is there some property or technique needed to force this repaint on any given particular event?
|
|
|
|
|
There is no setting to change. IMHO, background images behind MDIChild windows just makes the window look more cluttered, but it's my app...
What I think you're missing is the MdiParent form renders it child windows in a control, just like a Panel control is a container for holding and drawing other controls. That control is called "MdiClient" and it's automatically added to any form that is tagged as an Mdiparent.
Instead of setting the background of the MdiParent form, grab a reference to the MdiClient control by searching the Controls collection of the MdiParent form, then set the BackgroundImage property of the MdiClient instead.
|
|
|
|
|
I tried the following;
Private Sub frmMenuParent_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
'set the mdiclient bg image
For Each ctrl As Control In Me.Controls
If TypeOf (ctrl) Is MdiClient Then
ctrl.BackgroundImage = Global.snd.guiMainMenu.My.Resources.Resources._VisionMainMenuBackgrnd1024_768
ctrl.BackgroundImageLayout = ImageLayout.Stretch
End If
Next
End Sub
But the background image was still tiled, and not stretched. When I collapsed my menu the same behavior occured, where it seems the background moved instead of being redrawn to stretch the entire container area.
Any ideas?
|
|
|
|
|
From the documentation on the MdiClient class, it looks like BackgroundImageLayout is not used. Try changing the BackgroundImageLayout of the form instead, but you still have to keep this code that you posted to change the BackgroundImage of the MdiClient control.
As another possible option, you could try the Paint event of the MdiClient control (you'll have to write this up manually) and painting the background image yourself.
|
|
|
|
|
Well that suggestion definately made the initial drawing stretched, so I thank you on that. But the original issue still stands as when controls are hidden to expand the working area, the image is tiled, overlapped etc showing that it was never redrawn, just moved or nudged.
Dave Kreskowiak wrote: As another possible option, you could try the Paint event of the MdiClient control (you'll have to write this up manually) and painting the background image yourself.
I thought of this but was reluctant due to a performance hit, if there is no other way I guess I will implement this.
|
|
|
|
|
Just an FYI in case you where interested, the only solution I came up with where handling the Resize and RegionChanged events of the MdiClient and then calling an Invalidate() method on the MdiClient to force itself to redraw.
Not pretty or efficient, nothing else I could think of.
Thanks,
Elie
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
