This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi Just encountered one problem with using Oracle's ODP.NET. A simple example: Oracle.DataAccess.Client.OracleCommand commandOracle = new Oracle.DataAccess.Client.OracleCommand("select 1 from dual"); gives an error: I am pretty sure there's nothing wrong with connection settings and somthing similar, as querying model entites through that same UnitOfWork (just OracleCommand part commented-out) is working OK. It could be also a possible issue in ODP.NET, but I am really not sure what to complain to Oracle, I just initiliazed one OracleCommand (simplest possible, no tables used). We're using ODP.NET v. 11.1.0.6.20 (lib version 2.111.6.20) |
|
|
OK, trying some more, I've managed to resolve this through app.config redirection od assembly version (two versions of ODP.NET present in our system), so it looks like the problem was only in our system. Sorry for the trouble. |
|
|
As I raised the question of ODP anyway, I do have one situation which I can not "blame" LS currently directly, but could be possibly connected with ODP.NET version clash with the one LS is using. I regulary during compilation get warnings about versions conflict in Oracle.DataAccess. We have to use 11g ODP because of some column types supported only in it. And all our libs are compiled with that ODP. All warnings and application runtimes are redirected by app.config to ODP 11g version which strangely enough has worked, as I have found that usually assembly binding redirecting to a version which has a lower number won't work. Now, we have recently implemented some protection software for our libraries (injectes calls to some native dll methods), and this has worked for all libs, except the ones using LightSpeed. If you have any ideas on this, it would be really appreciated. Thanks anyway Marko |
|
|
Without knowing what your protection software is doing, it's hard to suggest what the cause of the problem might be. Binding redirects like you are using for the Oracle DLLs are a standard part of the .NET execution engine and if your protection software cannot cope with binding redirects then you should contact the vendor. Another possibility is that your protection software is somehow running into problems with LightSpeed's obfuscation. Again, obfuscation is not exactly an edge case in the .NET world and the protection software vendor should be able to handle it. We can provide details of the obfuscation software we use if this would help you resolve the problem with the protection software vendor. I would suggest that you create a project that reproduces the problem (i.e. works normally, blows up when protection is turned on) and provide it to your protection software vendor. We will of course be happy to work with your protection software vendor if they need more info about LightSpeed internals in order to solve the problem. |
|
|
Thanks Ivan. Yes, I am working on sample project, and hence the simple Oracle Command situation which started this thread. I also informed the protection vendor about the issue, but the ball is still in my court to pin-point the problem with as simple example as possible (which btw appear to be working so far). |
|
|
Rather than us supplying you with an unobfuscated version of LightSpeed, what I'd suggest is that for your investigation purposes you add your source copy of LightSpeed *as a project* to your test solution, and use a project reference instead of an assembly reference to bring it in. That will provide you with a better debugging experience. You could also try having your private build reference your real Oracle.DataAccess.dll so as to see whether the binding redirect is an issue. Obviously, we are suggesting this for diagnostic purposes only. And of course you would want to reset the project to using the normal obfuscated LightSpeed DLL before passing it to your protection vendor, so that the protection vendor is reproducing your real scenario. |
|
|
OK, did as suggested, and after heavy testing, encountered (for me) a surprising situation. Our problem lies with LS ConnectionStrategy. This is a bit out of my expertise-scope, and I am taking a guess, is it possible that you have some kind of compilation flags set or something similar, which disallows your lib to invoke methods/properties which have anything to do with unmanaged code?
|
|
|
OK guys, I have tried to make sample projects without LS with exactly the same situation - Base project having abstract class (simulating LS lib) and protected lib implementing this abstract class, and so far this has been working. The only conclusion I have so far, is that Lightspeed has some options selected making it run in security sandbox in relation to type of dlls which get called from it. But I could be wrong, as I said a bit uncharted teritory for me. So please, give some feedback when possible. Thanks |
|
|
We don't have any "compilation flags ... or something similar" that disallows calls involving unmanaged code. As you can see from the source, our call to GetConnection() is a perfectly normal .NET call. We're not even responsible for the loading of the protected assembly, which is where BadImageFormatException would usually appear: your application code gives us a ConnectionStrategy object, and we dumbly call its GetConnection method (which ultimately leads to a call to your overridden ConnectionStrategy.Connection getter). Also, no obfuscation is involved on this code path. I would suggest a couple of things: 1. Check the BIFE FileName and FusionLog properties for any info. 2. Build up your "non-repro" sample to make it more like your real scenario, until the error occurs -- or trim down your library until the error goes away. My suspicion is that the issue may be specific to your ConnectionStrategy.Connection implementation, and that something is flaming out when the protected code tries to resolve the Oracle libraries. E.g. what happens if you change Connection to just return null? (Obviously all your queries will fail, but does it get rid of the BIFE?) Or if you add the LightSpeed library to your "non-repro" project and implement, say, INamingStrategy? (E.g. implement GetTableName -- just to return the default name.) Can LightSpeed call an INamingStrategy in the protected library or does this also cause the BIFE? What if your INamingStrategy creates an OracleConnection (just for testing purposes, not to do anything with it of course)? Does this bring the BIFE? Etc. |
|
|
Thanks Ivan, I did some of these things already. FusionLog states no error loading assembly, BIFE also just error text "Bad IL format", no dll filename specified, nothing in exception details. protected override IDbConnection Connection } and same error is appearing. In debuging (or showing debug messages) our getter is not even entered, but rather at the moment LS lib calls it: boom! I also tried playing with your Going crazy a bit here... But will try something more, though not sure what at the moment. |
|
|
Whole day testing and the only combination so far giving an error is a getter returning IDbConnection in combination with LightSpeed lib.
On my repro-sample without LS, exactly the same concept of abstract getter with IDbConnection, this is also working (which unfortunately adds LS to the issue list). With returning OracleConnection, my repro-sample is also working (so, Oracle looks ruled out, for now). Fusion log (set to log all binds) specifies no extra assembly load request at the moment of exception. I've tried samples on a separate machine, to verify possible framework installation issues, same errors on that machine also.
|
|
|
I can only reiterate that we're not doing anything weird or special when we call ConnectionStrategy.Connection, and we have no special compilation flags to prevent people using LightSpeed with unmanaged or obfuscated code. You need to bring your protection vendor into this. We are very happy to advise, inform and assist in testing, but there's simply no way we can debug interop issues with a third-party product when we have no access to or information about that product. The only suggestion I can make without your protection vendor being involved is to duck the issue. That is, break out your ConnectionStrategy implementation into a separate DLL, and do NOT protect this DLL. Since ConnectionStrategy shouldn't have any dependencies on your other code, this should be trivial to do; and I can't imagine you care if bad guys reverse-engineer your ConnectionStrategy class. This seems to me to be by far the simplest, quickest and cheapest solution for all concerned! |
|
|
Ivan, thanks again for your support. Hence, I have informed our protection vendor with all the exact details found so far, to at least get as much information feedback as possible. BTW, the protection software we're using is HASP SRM from Aladdin, and it's main purpose is not so much about generally making reverse-engineering difficult, but rather making software being able to run only with the presence of special USB dongle key (in another words, disallowing software to be used on more places than bought). As I said, hopefully, at least knowing the enemy (pitfall) will be possible. And I do understand that because of the nature of the issue I could be involved in sort-of vendor "ping-pong" here :), and I would also like to avoid it. We really appreciate the support you are giving and have done so also on this issue, and I will try not to abuse it (more :) |
|
|
Agree, I too would like to understand the problem so it can be fixed "at source" rather than being worked around. We'd be happy to work directly with Aladdin so feel free to give them my contact details if they need to talk to us. |
|
|
Just a small update on the issue (also for anyone how would possibly read the thread later): Breaking the dll, and moving the "troublesome" getter into a separate dll is working OK so far. Aladdin is still "chewing" on the problem. |
|