all,
I'm looking into OpenSSL.NET and have hit a bit of a wall with it. As I said, I'm only looking into it, but a project at work needs to use it, so I can't really use anything else. The problem I'm getting is that I'm using the Cipher attribute to select an encyption type, yet each one throws the following error:
The type initializer for 'OpenSSL.Crypto.Cipher' threw an exception.
Also, when I look at the debugger, each Cipher has "null" as it's value. I've got the ManagedOpenSsl.dll referenced, and libeay32.dll and ssleay32.dll are both in the working directory, so I'm a tad stuck.
Any help on this would be much appreciated. Also, has anyone found any good stuff to read on the OpenSSL library? I've spent two hours looking, but nothing useful shows up.
Cheers
Related
I'm outputting two files from my program, the paths to which are supplied in user config.
I need to reference one file from the other so was happy to find the Path.GetRelativePath function however, this:
Path.GetRelativePath("/Users/ben/file1.txt", "/Users/ben/file2.txt")
outputs ../file2.txt
I can't see how that's correct; I would expect simply file2.txt or better still ./file2.txt
I'm using .net 6.0 on MacOS
There are lots of examples here of how to do this using Uri's, but can someone explain why this isn't doing what I'd expect...
Thanks
Thanks to #Alexey Larionov (see comments); I simply hadn't read the documentation properly; it states "[The first property] is always considered to be a directory".
So easy fix is
Path.GetRelativePath(
Path.GetDirectoryName("/Users/ben/file1.txt"),
"/Users/ben/file2.txt")
//returns file2.txt
One of my colleagues has added a test project to the master branch that includes a Moq reference. Its not even busing used at the time, simply having the reference causes the build and website to fail:
I called it a pseudo random issue in the title because I've also have that happen with the same error but:
System.Buffers
Once it's set, it's pretty consistent, so no clue what the trigger is to throw on a different library.
If I remove the website from the solution, the code builds correctly, but the website still shows the issue in the browser (as you would expect, I guess).
If I remove Moq and all of the traces adding that exist for the dependency (and it's children), the build is working again
Another reason why I call it a pseudo random issue is that I suspect that what I see is a symptom of the issue. Not the issue itself. It just so happens to trigger on System.Runtime.CompilerServices.Unsafe or whatever.
Any ideas / tips on what I can do to:
Find the actual issue
Come up with a solution?
PS: In case it could be important, we are on a deterministic build, not the default.
With more time passed it's clear that its an architectural fault. A thorough restructuring is needed to fix that so sadly no easy answer can be provided for this.
I've been on a quest for a while now to pass the PCM of an MP3 from W8.1/WP8.1 to Unity3D and I believe I'm getting close. I was referred to this project which works absolutely fine but, of course, it's in VB.NET so it can't be used with Unity. VB and C# are fairly similar so I set out to translate it. You can see my translation at this pastebin.
The problem occurs on line 97. The app simply exits with absolutely no indication of what went wrong. Calling any non-inherited function on the interfaces IMFSample and IMFMediaType has the same effect.
A friend suggested getting the HRESULTs from these functions to see if anything shows up. Google shows getting HRESULTs from COM interops in C# is.. hard. I experimented by changing IMFSample.GetSampleFlags to
int GetSampleFlags(out int pRetVal);
And that returned "The requested attribute was not found. (Exception from HRESULT: 0xC00D36E6)" and I'm not really sure what to do with that information...
So, I humbly ask you all... just... just what? What do I do from here?
--- SOLUTION ---
So as it turns out the solution was a little dumber than I expected.
I did not know this, but apparently COM interfaces that inherit from other COM interfaces have to include ALL of the methods from the parent COMs. Otherwise windows, it seems, throws a hissy fit.
That was it... it was my own laziness in the first place that killed me.
My Google-Fu has obediently told me that the following error
Not able to perform the operation because object is not given storage yet (Exception from HRESULT: 0x80040012 (OLE_E_NOSTORAGE))
which is being thrown from a C++ function called in a C# project is, in fact, an error which is related to OLE. But I can't find much more beyond that - what might cause such an error, or what functions would return it.
More baffling is the fact that although I know the code I'm using has spat out this error before, I personally haven't been able to reproduce it. It's coming from a pair of unit tests, so I doubt that I'm missing some vital step to reproduce the error, unless it's due to some arcane machine configuration. Can anyone help me understand where it might be coming from?
I'm working on some code that dropped on me when another developer (and the only person who knew anything about this system) left. I'm trying to figure out why my client and server are not connecting. I'm getting the following error:
"Genuine channels operation exception: The connection has been forcibly closed.
Specified reason: RSA encryption failed with error code = -2146893819"
Initial google research seems to indicate that Genuine Channels is a communications library that was being used (but I'm not sure if that's accurate). Also, there doesn't seem to be any information on what that particular error code means.
At this point, I'm fine with suggestions on where to give my research if you don't have any concrete ideas on what could be wrong.
Error code -2146893819 is hex 80090005 which, in the MS crypto libraries, is NTE_BAD_DATA.
That's about as far as I got before I lost interest (that tends to happen to me a lot with crypto stuff) and it's only slightly more helpful than what you've got, so I've made it community wiki.
You haven't actually stated what you were doing when you got the error but the top hit for "rsa" and "nte_bad_data" on Google was this.
Still, it expands you Google search terms at least :-)
Best of luck.
For reference to future people who visit this question, I eventually solved this issue. It turned out to be a a DLL mismatch between the versions of GenuineChannels & our cryptology implementation that were on our client machines and our server machines.