We Keep Coding

My dll is not working in a project on another pc

I wrote my class library in c#. It uses a couple of nuget packages and another dll downloaded from the Internet (visacomlib.dll) I connect it to another (console) project, this bundle works on my computer.
If you compile the final project, it also works. However, if you transfer the compiled project to another PC, an error appears:
System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLID.

I partially solved the problem in the following way:
Be sure to install the NI_visa drivers.
Assembly in Rider did not work. On another PC I get the following error:
Unhandled exception. System.Runtime.InteropServices.COMException (0x80040015) HRESULT = 80040015
at VisaComLib.ResourceManagerClass.Open(String ResourceName, AccessMode mode, Int32 openTimeout, String OptionString)
However, I built the same project with default settings in Visual Studio and everything worked.
If everything turns out so well to make a working assembly in Rider, I will supplement this answer.

IBM.Data.DB2.Core throws exception in azure function app

I'm using nuget package IBM.Data.DB2.Core version 1.3.0.100 dll to connect DB2 database from Azure functions with AzureFunctionsVersion V2. Application builds successfully.
When I run the application and hit it with Postman I get the exception:
System.Private.CoreLib: Exception while executing function: Personal-GetAgencyDownload. AgencyDownload: Could not load file or assembly 'IBM.Data.DB2.Core, Version=1.2.2.201, Culture=neutral, PublicKeyToken=7c307b91aa13d208'. Could not find or load a specific file. (Exception from HRESULT: 0x80131621). System.Private.CoreLib: Could not load file or assembly 'IBM.Data.DB2.Core, Version=1.2.2.201, Culture=neutral, PublicKeyToken=7c307b91aa13d208'.
I see the 1.3.0.100 package, there isn't any other package. Why is it looking for 1.1.1.201 in runtime?

Know this is a little late, but just in case others have this issue with the latest version of IBM.Data.DB2.Core (version 3.1.0.300 at time of writing) for me it was due to the Azure function platform defaulting to 32bit, and the IBM dll (or one of its dependencies) required 64bit. Changing the platform setting to 64 bit resolved this error.
You can find the setting under configuration > general settings in the azure portal.

This could happen if you have the IBM.DataDB2.dll file lying around in directories other than the DB2 client install location. This could have happened without your knowledge where Visual Studio copies the necessary dll into the bin directory of the project.
IBM.Data.DB2.dll has dependencies on other client libraries in DB2 Client installation. So refer the DLL from the DB2 Client installation location only and do not save a local copy in the application directory.
Go to the reference in the project and set Copy local to false for DB2 dlls, referencing directly the ones from the DB2 client setup.

Need help in modifying OWIN (Katana) for running VS2013's MVC WebApplication in Raspberry Pi

I want to run Visual Studio 2013's default MVC WebApplication in Raspberry Pi 2. I managed to install mono 4.0.1 and Lighttpd as the web server, and I was able to get this default MVC WebApplication (with no authentication) run on the Raspberry machine. However, when I tried the same MVC WebApplication but with "Individual Authentication", it gives the following error:
System.MissingMethodException: Method 'HttpApplication.RegisterModule' not found.
After googling, I found it here that this method 'RegisterModule()' is not implemented in mono's System.Web.HttpApplication. And the solution is to rebuild OWIN. I have never done that before. I used 'Git Bash' to clone the Katana as follow:
git clone https://git01.codeplex.com/katanaproject
then modified the PreApplicationStart.cs accordingly, and then run 'build' in command prompt, and it successfully created the Microsoft.Owin.Host.SystemWeb.dll under the project directory. I then tried to replace the original dll with this new one in Visual Studio 2013, and hit F5 to try to run it, and get the following errors:
The type 'Microsoft.Owin.IOwinContext' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.Owin, Version=3.0.1.0, Culture=neutral, PublicKeyToken=null'.
and
'Microsoft.Owin.IOwinContext' does not contain a definition for 'GetUserManager' and the best extension method overload 'Microsoft.AspNet.Identity.Owin.OwinContextExtensions.GetUserManager<TManager>(Microsoft.Owin.IOwinContext)' has some invalid arguments
Is this the proper way to rebuild the OWIN and update this Microslft.Owin.Host.SystemWeb.dll? Any suggestion to get it work?
Thanks.

Got it work by using Visual Studio 2013 to build the project Microsoft.Owin.Host.SystemWeb directly, then use the result Microsoft.Owin.Host.SystemWeb.dll to replace the one used in the original MVC WebApplication project.

Could not load file or assembly 'Interop.QBFC8Lib' or one of its dependencies

I am using a quickbooks sdk that containst the QBFC8Lib dll
everything works fine on my dev machine.
when I publish to my live server I get the following error:
System.BadImageFormatException: Could not load file or assembly 'Interop.QBFC8Lib' or one of its
enter code heredependencies. An attempt was made to load a program with an incorrect format
I have the sdk installed on both my dev machine and the live machine. still getting this error

You areexactly right. on the server I went to the application pool for this application and needed to set enable 32 bit applications to true. That did it. Thanks for your help

Can not reference a Dll that worked earlier

I am trying to change the Terminal Services settings programmaticly. I learned that you must use tsuserex.dll. Being c# i ran tsuserex through tlbimp and created TSUSEREXLib.dll then registered it with regasm. I got it working and wrote a framework program with it as a prof of concept. However today after I made some changes when I run my program I get the error
Unable to cast COM object of type 'System.__ComObject' to interface type 'TSUSEREXLib.IADsTSUserEx'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{C4930E79-2989-4462-8A60-2FCF2F2955EF}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).
it thows the exception on the line
IADsTSUserEx iad = (IADsTSUserEx)((DirectoryEntry)user.GetUnderlyingObject()).NativeObject;
This exact line worked fine in the test project. I know user is a valid UserPrincipal, Googleing I found this is usually just needs the dll re-registered, but even after unloading and reloading it it still will not work. What am I missing to cause my dll to stop working.

I know this is an old thread but since I had trouble recently finding all the required steps to get the Terminal Services components working on Windows 7, I wanted to share what I found. I think the steps below are more reliable than copying the tsuserex.dll from a server and trying to register it.
From what I understand, on any operating system you need Remote Server Administration Tools (RSAT) installed in order to modify Terminal Services attributes of a user account programmatically. On some versions of Windows this requires a download. But on Windows 7, RSAT is already installed.
But you may need to enable it using the configuration options in Control Panel (appwiz.cpl). Under "Turn Windows features on or off" goto "Remote Server Administration Tools" then ensure that "Remote Desktop Services Tools" is checked.
After I did this (and rebooted) I was able to use the components from tsuserex.dll via PowerShell (e.g., Set-QADUser -Identity testUser -TsHomeDirectory "c:\tshome"), and by adding a reference in Visual Studio 2010 (to "tsexusrm 1.0 Type Library").

You almost certainly need to re-register your TLB on the target machine. What likely happened is you have your assembly, interface or type GUID not hard coded in the application and hence it's changed on every rebuild. So after rebuilding and deploying your type no longer matches up with the previously registered TLB.

The correct answer is that I am a idiot for not reliseing that my build environment did change. I moved to a new workstaion that was windows 7 corprate instead of server 2003 when i started on the project. Win7 corp does not have tsuserex.dll in its system.

Visual Studio Build Setting „Platform target“ disable=> “Prefer 32-bit” solve the Problem.