We Keep Coding

License error using Benchmark.NET + DevArt dotConnect for PostgreSQL

I'm working on an application consisting of several projects and using EntityFramework with dotConnect to run against PostgreSQL. I also have a license for dotConnect which successfully works in the main application.
In parallel, I'm crafting a console application(a different solution) using Benchmark.Net to measure the performance of the logic of one of the projects. But every time I run the benchmark I'm getting the error below:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Data.Entity.Core.EntityException: The underlying provider failed on Open. ---> Devart.Data.PostgreSql.PgSqlException: Assembly that contains embedded dotConnect for PostgreSQL license cannot be used with this application: 0f238e83-669a-46b8-876f-40331880ee79.exe.exe.
Following this instruction, I have already generated licenses.licx through Visual Studio and <exe file>.licenses via lc.exe. But it is still producing the same error.
I'm suspecting that the fact that Benchmark.NET generates its own exe to run the benchmark causing this error but I'm not 100% sure. So I'm looking for a solution if anybody has one?
Thank you

I'm not sure it's a good idea to create a benchmark for code that does database calls etc. You're benchmarking not the code then, but your whole system instead: the file system, the database drivers, possible interop stuff, and so on.
This is not the idea of BenchmarkDotNet. It's actually created for benchmarking of relatively small CPU-bound tasks to find bottlenecks and perform optimizations based on measurements.
However, if you still want to do that, a solution might be to run the benchmark in-process of the console app you've created, without producing special benchmarking assemblies.
To do so, use the [InProcess] attribute. Just apply it to your benchmark class instead of usual job attributes:
[InProcess]
public class TypeWithBenchmarks
{
[Benchmark]
public void BenchmarkedMethod()
{
}
}

How do I open OLEDB Prompt for 32-bit from x64

Good day everyone,
I am writing a C# application that will allow users to dynamically set the database they want to connect to (I'll work a bit with the database data and such, but that's not important). The important part is that I'm allowing my users to connect to data-stores from OLEDB using the code below.
ADODB.Connection connection;
MSDASC.DataLinks instance = new MSDASC.DataLinksClass();
if( (connection = instance.PromptNew() as ADODB.Connection) == null ) return;
This will open the very same Dialog that windows opens for *.udl files, and that's exactly what I want.
However, I hit a interesting problem to which your brightness could come in handy: some customer WILL have to browse for x86 drivers, and the vast majority will certainly use x64.
I know you can open x86 UDL files with the following command-line:
"C:\Windows\syswow64\rundll32.exe" "C:\Program Files (x86)\Common Files\System\Ole DB\oledb32.dll",OpenDSLFile "C:\myConnectionFile.udl"
When the default (64 bit) command is:
"C:\Program Files\Common Files\System\Ole DB\oledb32.dll",OpenDSLFile "C:\myConnectionFile.udl"
In other words: windows' allowing users to create entries in both fashion. I would like to do the same in my app, using the API.
I have considered the option of creating a temp UDL file and opening from the command-line above, which made my conversation with my technical lead rather unpleasant, so that's not an option.
All suggestions are welcome. I will not dismiss unsafe coding nor the thought of building wrapper in C++ if we get to that (although my C++ is inconveniently rusty nowadays).
Thank you all in advance and happy coding...

Good day fellow developers,
After a tedious and lengthy research process I have around the answer I was looking for.
In order to use OLEDB providers for both 32 and 64 bit platform from one single C# 64bit app I'll need to create an Out-of-Process Wrapper to the 32bit call, and make the call over IPC (Internal Process Calls). Because the amount of functionalities I'm exposing is moderate, the hindrance was just re-creating some method calls on the wrapper.
This blog helped me put the parts together, and now I'm able to determine what type of OLEDB connection I'll allow my user create, and I'm also able to perform all operations I need regardless of the Provider Architecture.
I hope this will benefit other people who might be having the issue.
If time (and NDA) allows, I'll get the code here for people to copy and try it later.
These links were also very useful on my research
http://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/
Registering the DLL Server for Surrogate Activation
https: // msdn.microsoft.com/en-us/library/windows/desktop/ms686606(v=vs.85).aspx)
Writing Serviced Component
https: // msdn.microsoft.com/en-us/library/3x7357ez(VS.80).aspx)
How to: Create Serviced Component
https: // msdn.microsoft.com/en-us/library/ty17dz7h(VS.80).aspx)
Create Out-Of-Process COM in C#/.Net?http: // stackoverflow.com/questions/446417/create-out-of-process-com-in-c-net
Thanks everyone
D

How to Determine If .NET EXE was started by another process

Forgive me if my title is not accurate, I did my best to describe my issue.
Here's the details, I can modify accordingly:
I've been upgrading a VB6 application to a .NET (VB.NET and C#) application to be used in Excel. Using my application's ProgID, I can query it in Excel VBA using:
CreateObject("MyExe.MyApp")
Since I believe my app is a single-instance application, when I call CreateObject and it is already running, it just returns me that running instance. All is fine there.
My issue is, when it is NOT running, it will launch a new one right? That's my problem in my .NET application. You see, in VB6, when you use CreateObject, it will change my App.StartMode to VbSModeAutomation = 1
My VB6 application handles this accordingly. However, there doesn't seem to be an equivalent way of doing this for a .NET application. In fact, it says right on this MSDN page:
StartMode - No equivalent. In Visual Basic 6.0, this property was used
to start an application as an ActiveX component. ActiveX component
creation is not supported in Visual Studio .NET.
So ultimately, my question is: how do I determine when my .NET application is started from this call to CreateObject versus starting it manually (or via standealone, like a shortcut or etc.)?

.NET does not as easily let you create an out-of-process COM server, like VB6 does with that VbSModeAutomation property. The supported scenario is COM+ hosting, your [ComVisible] class needs to derive from the ServicedComponent class.
There's a dedicated KB article that summarizes the required steps pretty well. The in-depth MSDN articles start here.

Checking for a parent process is quite tricky but you can find the information in the Win32_Process WMI class - ParentProcessID property. If this is not set then your application was not started by another application.

You might be able to use the CommandLine to determine how it starts. It does not appear that CreateObject allows you to pass command args, but as you noted, -Embedding seems to automatically get sent. Alternatively, maybe you could modify the shortcut method to pass some fake argument and its absence could indicate a CreateObject start method.
NET supports several ways to get the commandline:
Environment.CommandLine and Environment.CommandLineArgs()
I think there is another in the VB Namespace but it returns a collection of objects rather than String or String array of parsed args (space delimited).
You can also modify your Sub Main:
Public Sub Main(args() As String)
NET will fill in the array with the parsed commandline

Change hardcoded value in executable

A new game released has been provided with server files that do not currently have the option of configuring an IP Address/Port for binding. Unfortunately this limits the ability to run more than one instance of the application per machine as it is hard-coded to port "12345".
Many years ago I was using c++ and hex editors to change hard coded values like this and while that knowledge has long since been forgotten, would it be possible to improve this by writing a secondary application to change that value at runtime?

You still can use hex editor in order to change the hard coded constant.
Another way is to use debug api, provided by any decent OS. In Windows it is WriteProcessMemory function.
It looks following way - the launch application runs the modified application in debug mode. Changes needed constant and then runs it.
Of course, the modified application may use anti debugging techniques - in this case the solution is not trivial.
In both cases, you have to know where this value resides in the memory (executable file). This way some reverse engineering have to be provided.
Note, after the last question edits: All this answer is for native executable files. For managed code it probably is more complex.

Deploy a CLR Trigger/Stored Procedure using WiX

As the founder's of stackoverflow talk so much about being able to deploy changes easy, I'm trying to come up with a solution to solve my issue. A quick background is that a client contacted me and needed something done on the database that is quite not so trivial, but isn't horribly difficult to do (took me about a day to get the procedure to work). Unfortunately, the client needs to be able to deploy this "fix" about 20 times, and without my input, as he isn't going to pay for it.
I have written a CLR trigger that does some work that would otherwise be very difficult using TSQL (xml document transformations.. I'm better at it using CLR vs. TSQL). Deployment is typically a few lines SQL and dumping the dll to a directory from what I can fish out (I've only ever deployed from VS.Net so far).
What I need to be able to do is to provide an MSI installer that will drop the file to a folder, and prompt the user for the database information that is required to connect the CLR procedure to the correct database/table.
Has anyone done this in the past, and if so, are you willing to school someone on how this is done, so I can get this project to bed?
Thanks

If you want to avoid the trickiness of placing the file, you can use the alternate form of the CREATE ASSEMBLY statement that specifies the assembly in byte form.
e.g.
CREATE ASSEMBY MyAssembly FROM 0xFFFF....;
Obviously, you would have the actual assembly bytes where I've put 0xFFFF.....