|
|
Hello there. I am using FrameGrabber to get me the images which I then use in MainForm - 2 self developed classes. But it gives me the said exception. Here is the relevant code for both classes.
------------ FrameGrabber ----------------
static object m_obj = new object()
Bitmap CurrentBitmap = null;
public Bitmap CurrentFrame
{
get
{
Bitmap bmp = null;
try
{
lock (m_obj)
{
if (CurrentBitmap != null)
bmp = new Bitmap(CurrentBitmap);
}
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
return bmp;
}
}
private void OnNewFrame(Frame frm)
{
Bitmap current_bitmap = new Bitmap(frm.Image);
lock (m_obj)
{
if (current_bitmap != null)
{
if (DateTime.Now.Subtract(LastFrameSendTime).TotalMilliseconds >= FrameDelay)
{
LastFrameSendTime = DateTime.Now;
CurrentBitmap = new Bitmap(current_bitmap);
}
}
}
}
And here is the code for MainForm .
------------ MainForm ----------------
bool isplaying = objFrameGrabber.Player.IsPlaying;
while ((isplaying))
{
Bitmap current_frame = objFrameGrabber.CurrentFrame;
while ((current_frame == null)
{
System.Threading.Thread.Sleep(10);
current_frame = objFrameGrabber.CurrentFrame;
}
picLiveVideo.Image = current_frame;
}
As you can see, I am using lock in FrameGrabber class. What could be wrong ? (I can provide full stack trace if needed) Thanks for any input.
|
|
|
|
|
Something that jumps out at me from your code is that you are creating an awful lot of Bitmaps, and not disposing of any of them. Bitmap wraps an unmanaged resource, so you should really get in the habit of releasing them.
This space for rent
|
|
|
|
|
(I'm not sure if this would be better asked in the COM forum... or QA...)
Is there a way to implement C#-implemented functionality via COM (for adding to legacy code) in such a way that I need build only an AnyCPU targeted dll that can then be used via COM either 32 or 64 bit?
================
Update May 18, 2016:
As it turns out, setting the build target to AnyCPU and selecting the "Register for COM interop" in the build settings does work. It appears to register the class in both HKCR and HKCR\Wow6432Node\CLSID (and the interfaces and type library in both, as well).
In my defense, this was originally written in C#, and the 32 bit COM requirement was added, so I first went down the explicit 32 bit COM path, and then I tried to add the 64 bit COM. If I had known about the COM up front I probably would have just done it this way in the first place.
And lest anyone blame the provider of the requirements...
I started this side project because I overheard coworkers discussing how to solve this conceptual issue and what they were thinking was only going to give the appearance of solving the issue. I thought that the correct solution shouldn't be difficult, so I started. When I told them what I'd accomplished, then they informed me of the COM requirement (for use by the legacy application).
================
I have a C# assembly that implements some functionality and it works fine when invoked from within C#.
There's one entry point class which implements the functionality, and exposes a support class's functionality via another interface.
Like:
public class DSS
{
public ITSF TSF { get; private set; }
}
public interface ITSF
{
string Prop1 { get; set; }
}
I have enabled COM using the [assembly: ComVisible(true)] in the AssemblyInfo.cs.
I then added [ComVisible(false)] for things I didn't want visible to COM. (Doing it the other way around didn't seem to do the "right thing".)
[ComVisible(false)]
public class DSS
{
public ITSF TSF { get; private set; }
}
[Guid("...")]
[InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
public interface ITSF
{
string Prop1 { get; set; }
}
I wrote a separate class to wrap the entry point class, and it implements an interface to expose the functionality in a COM-friendly way. (I.e., different names for overloaded methods, ...)
It inherits from the DSS class.
Like:
[Guid("...")]
[ClassInterface(ClassInterfaceType.None)]
public class DSScom : DSS, IDSS
{
public ITSF TSF { get; private set; }
}
[Guid("...")]
[InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
public interface IDSS
{
ITSF TSF { get; }
}
I then added the "Register for COM interop" setting in the project properties.
So far, so good. This all builds. (Yes I needed to run Visual Studio 2013 as Administrator...)
Then I wanted to build for both 32 and 64 bit. (It isn't clear if the legacy application will be converted to 64 bit when it uses this via COM.)
So I added two additional build configurations (Debug32 and Release32) and set the Platform target to either 64 or 32 appropriate for the configurations.
Trying to build both configurations would fail, apparently when it was trying to unregister the previously registered, other size, dll, before registering what it had just built.
Side note: There are different versions of regasm.exe for 64 and 32. I managed to get this working, I think, by unchecking the "Register for COM interop" and adding a post-build step that registers the dll with the correct regasm.exe. At least, it doesn't fail and I think the registry info is correct. What's the easiest way to check both sizes of the COM implementation? Any suggestions?
So all of this seems to work but is there an easier way to do this so that I don't have to do all of the size-specific .BAT file PATH hackery and separate registrations? Is there a way to just build for AnyCPU, and register the COM to "just work" in 32 and/or 64 bit?
Thanks,
Matt
"Fairy tales do not tell children the dragons exist. Children already know that dragons exist. Fairy tales tell children the dragons can be killed."
- G.K. Chesterton
modified 18-May-16 12:50pm.
|
|
|
|
|
I think Ive seen two 'part solutions' to this,
- the first involved late loading with LoadLibrary from c# ...
- the second involved modify the dll search path using ? SetDllDirectory
Both techniques mean you had 32 and 64 bit builds of the assembly that used the COM library
I'll see what I can dredge up, Im interested in this myself
|
|
|
|
|
Garth, I think you misunderstood the issue.
I have a C# assembly that is exposing functionality via COM.
I will be using it both from a managed C# application
and a legacy application: old, unmanaged C++ that can't be wholesale ported. (But ought to be!)
I'd like to register a single AnyCPU dll so it can be used if the managed application is either 32 or 64 bit, as well as by the legacy app via COM.
I suppose I can only register the 32 bit COM, at least for now.
But can I do that with an AnyCPU dll, or do I still need to build two versions of the dll: 32 bit (==x86) for COM, and AnyCPU for managed app use?
"Fairy tales do not tell children the dragons exist. Children already know that dragons exist. Fairy tales tell children the dragons can be killed."
- G.K. Chesterton
|
|
|
|
|
|
Couple of problems here:
1) This is not a good question - we cannot work out from that little what you are trying to do.
Remember that we can't see your screen, access your HDD, or read your mind.
At a guess, you are trying to write a "bible search" program - but that's all I get.
2) Don't post links to images: most people won't follow them because they have no idea what they will find on the other end. Describe your problem in detail instead. (This is a very worthwhile thing to do anyway: you frequently find the solution just by a process of meticulously documenting the problem!)
3) If you are going to post a link for people anywhere, make sure that anybody can open it. You link requires me to sign in as you in order to access the image...
4) Tell us what you have tried; where you are stuck; what help you need. Don't assume we know the context of your application, because we don't! And your app is probably in C# (or you wouldn't post here) but it could be webapp, website, winforms, WPF... it could use SQL Server, MySQL, SQLite, Access, XML, text, CSV ... we do not know. You need to tell us the relevant facts around your project in order to get a meaningful answer.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I just started learning about client server architecture. And I want to create client server application which can send request and receive response. Firstly I want to do communication between client server without any security. Later I want to add Open SSL to my application and check the security level. Is it possible? What is the best way or example to create Http client server application? Any suggestion or Help or reference?
|
|
|
|
|
This is not a question that can be easily answered in a technical forum; you should use Google to find samples of the various parts you are interested in. Here is one to get you started: HttpWebRequest/Response in a Nutshell - Part 1[^].
|
|
|
|
|
Hi, recetly, i found .net code .exe file can be decompile easily ,and other one can get your code in detail ,but my code has some secret,so i don't hope other one can decompile my code easily.
how can i do it?
|
|
|
|
|
You can't, and your code should not contain secrets.
You can make it "harder" to read by obfuscating it; that means that it will take me more time to read it.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
All security is really about is making something more difficult. The best you can hope for is to make the cost of acquisition higher than the value of acquisition.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Nathan Minier wrote: The best you can hope for is to make the cost of acquisition higher than the value of acquisition. For a hobbyist, cost is zero; I can remember how many games were pirated, not too long ago - often within days of release, and that was usually not done using .NET reflection
Given the "genuine" application, I'd say that even Microsoft lost that battle.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
You can try various obfuscation tools that make your code much less readable; some of the expensive ones (and, I mean very expensive) claim to make it extremely hard to reverse-engineer code. But, all .NET apps are to a large extent accessible.
To really get security you need to use extra measures, which may include hardware dongles, or installation software that binds your app to machine specific identification and limits its use.
I suggest you start exploring some of these sites: [^].
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
You're mixing up two subjects here: Protection against reverse engineering (which is what the OP is asking for) and license enforcement. Dongles and hardware keys don't protect against reverse engineering.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Hi Sascha,
I see your point, but I think my including hardware protection is relevant; if you can't install the whatever containing the code, doesn't that help protect against reverse engineering ?
An academic issue, I know, since skilfully hackers regularly crack the most supposedly secure code and sites in the world.
cheers, Bill
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
|
|
|
|
|
If someone can reverse engineer your code, they can remove the Hardware lock validation code from that.
|
|
|
|
|
Hi Bill,
I see two reasons against considering hardware keys as a reverse engineering measure: You wouldn't be able to offer demo versions of your software and buying a license of your software wouldn't be a hindrance to those who think they could really benefit from reverse engineering your software.
cheers, Sascha
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
To elaborate a bit on what Eddy and Bill said: There are different so called obfucscator tools which will take your compiled .NET binaries and apply various kinds of transformations which don't (or: shouldn't) alter the programs behaviour but make the reverse engineering process harder. Ref: Obfuscation (software) - Wikipedia, the free encyclopedia[^] (also follow the links under the section "See also"). Those transformations differ in the increase of required effort for reverse engineering. They can be combined. They can have negative side-effects like braking .NET reflection (or requiring it to be programmed differently) or rendering exception stack-traces useless (because unreadable) unless the obfuscator provides a helper tool to make the stack-trace readable again. The pinnacle (to my knowledge) of those obfuscation methods is code-virtualization[^] which has the drawback of slowing down the code execution. No obfuscation method or combination thereof reliably protects your code against reverse engineering, they just make it harder. And, obviously, the tools vary in price, from free to some thousand bucks. Theoretically, the important question would be: How much effort do you think would someone interested in your source code be willing to invest into reverse engineering? If the required effort exceeds the effort to write a similar software from scratch then they will rather write their own software. Unfortunately, I can't help with estimating the required effort for reverse engineering code protected by this or that obfuscation method as I'm not a "hacker". My best advice is to read up on the various obfuscation methods and develop some sort of gut-feeling for which tool might suffice for you.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Member 12431039 wrote: how can i do it? Basically, you can't because ultimately, your code will have to conform to a defined language in order to run.
All you can do is make it more difficult to read after decompiling.
With enough will and mean, absolutely anything can be decompiled.
Patrice
“Everything should be made as simple as possible, but no simpler.” Albert Einstein
|
|
|
|
|
Software as a service.
Put your "secrets" in the cloud and provide an API that requires credentials to access your "secret functions"; whether via desktop, mobile or browser.
|
|
|
|
|
Next question; "How do I stop people using tools like Fiddler?"
|
|
|
|
|
The "algorithms" run on the server.
I don't give a twit about the transmission.
|
|
|
|
|
It depends what kind of secrets you are talking about.
If you mean that you have written the best algorithm ever, and don't want people to be able to copy it then you are out of luck. As stated in other answers, you can make it more difficult but not really prevent it.
If you mean you have stored a password or other secret user information, the answer is don't do it.
Passwords should be hashed in a proper way and other information is better kept on a secure server.
|
|
|
|
|