It's my first time asking on stackoverflow.
So I have this VSTO excel addin project that targets .NETFramework 4.8 and which references a few net standard 2.0 in-house libraries. One of the library uses nmath to make some pricing.
The project works very well in debug mode, I launch the excel, the Add-in is there and no error while running all the functions but after publishing I get this error when running one of the function :
Unable to load DLL 'nmath_native_x64.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
at CenterSpace.NMath.Core.DotNetBlas.dcopy(Int32* n, Double* dx, Int32* xStride, Double* dy, Int32* yStride)
So to summary it seems that either it doens't get the right version of nmath after publishing or it just doesn't load the dll.
I have tried many things like multi-targeting frameworks, removing all warnings etc etc but nothing seems to work at the moment.
Related
I am putting together a VSTO addin for MS Outlook. The addin is designed to utilize a unmanaged C++ library. Access to the library is via a C++/CLI (CLR) project. I am receiving a
File Not Found
error when running the ADDIN directly. It appears that the addin has difficulty with the associated unmanaged C++ library. The library is completely packed within the C++/CLI project and nothing using it requires knowledge of the unmanaged C++ library. The strangest aspect of this situation is that If I launch the ADDIN from Visual Studio all is loaded properly. I've validated that all libraries being used are where they are suppose to. It is unclear to me why the addin would fail to launch (when not being launched from Visual Studio).
Note: I validated this by running a test where I created a C++ library with one class and a C++/CLI library with one class that instantiates the class from the first library. I attempt to connect to the C++/CLI library from a VSTO project. I get the file not found error. I felt this was the simplest test to validate / determine what was happening.
Peter
Peter
The issue dealt with my making assumptions based on where things were placed. I had an installer that deployed the addin to the target deploy location. All files went into this folder. MY thinking was that if all the libraries are located within the same location they should all be found. This was based on the my thinking that an app runs and looks locally first for files. My mistake was that the app being run was Office Outlook - and it runs in a specific folder location. When I got the file not found I was thinking this can't be because the files are all together. BUT Office products when loading ADD Ins do not look in the location that the Add In is identified to be in (at leat for un managed DLLs - managed -- maybe different).
The end result was that the unmanaged DLL was not locatable because it did not show up in any of the seath locations of Windows. So the correct was to update the path to have the location of that add in. Which solved the issue of not found. What is annoying is that Visual Studio debugger -- looks to be working on the aspect of identifying DLLs where the application is being launched from. Which in general is fine -- except with VSTO the app being run is somewhere else -- but VS still looked in the project folder location to find the files. Making it somewhat unclear. This should not be occurring. VS debug should try or at least be configurable to operate in the context of the real world scenario. If it does -- I certainly was not able to find that configuration.
Peter
Visual Studio 2012
VB.Net
.NET 4.0
Build Machine x64
Build Config AnyCPU
msado27.tlb
This project is not new and has been built 100s of times over the past 2 years. With in the past 3 weeks something has changed and a COM reference to the Microsoft ActiveX Data Objects 2.7 library is no longer able to registered. When I try to reselect it from the available COM entries it is visible and selectable.
Com reference list
After selecting you can see the yellow triangle
reference tree node with yellow triangle
Then viewing it thru the its properties you can then see there is no path being shown.
reference properties
When viewing thru the project properties -> references it display
project properties references
If I select a newer version such as 2.8, 6.0, or 6.1 they will register. However if I select an older 2.5 it acts the same way.
Any suggestions or theories on what may have happen or how to verify if the .dll in the GAC or Primary Interop Assembly actually has definitions and or implementation for version 2.7?
And by the way I do realize that this is an extremely old version, but this current .Net project has additional COM references/dependencies which rely on this particular version and I am unable to switch to a newer version at this time.
Well after a painful day and a lot of wasted time I decided to go the route of re-registering the types again using regasm which I didn't think really had a chance of fixing the problem. Low and behold that was the problem.
The fix for me...
Open the developer console for VS2012 as Administrator
Navigate to the GAC area for your adodb.dll #
%windir%/assembly/gac/adodb/7.0.3300.0__b03f5f7f11d50a3a
Then run the command "regasm adodb.dll" and you should receive the
"Types registered successfully" message
Return to VS2012 and all current references to
Note: Early on when reviewing the registry values for the type libraries found in the adodb.dll file I noticed that the version that would not register in VS (2.7, 2.6, and 2.5) did NOT have Primary Interop Assembly value for there keys as the newer versions did. After running regasm those value were added in for the older versions.
Shows primary interop assembly info for v2.7 after running regasm
I have an EXE in VB6 that calls a recently upgraded to VB.Net DLL. This part is working fine, but the issue that I am running into is related to locating the interop of another COM DLL the VB.Net DLL references.
An overview: EXE (VB6) calls method A of DLL (VB.Net), no issues. Method A of DLL calls method B of third party DLL (COM), it gets an error of not being able to find the interop file of the COM DLL.
I have tested directly in VB.Net using a test UI to call the same method A in the VB.Net DLL, and everything works fine. I am currently at a loss as to what is causing the issue.
Thanks,
Chris
I have finally found the answer to the issue. All said and done, the issue was that the interop assemblies were framework version 4.0 instead of framework version 2.0. Visual Studio created them this way for some reason, so I had to change them by using Visual Studio 2008 to create new versions of them.
The process to find this out (which most of is already stated above, but repeated here for helpfulness) was to place all my VB.NET dlls and the interop assembly dlls in the directory of the VB6 exe. (I created sub folders for each one for easier cleanup later.) This still resulted in the same error, but the assembly builder log showed a different reason for the error. This time it was able to load the assembly without issue, but was not able to complete the setup of the assembly.
Researching this led me to the idea of checking the framework versions of the interop assemblies using ILSpy to find out they are version 4.0 while my dlls are version 2.0.
Initially I tried recreating them in Visual Studio 2017, since my project uses framework 2.0, but it still created them as framework 4.0 for some reason. I then tried in Visual Studio 2008, and it was able to create the correct framework 2.0 versions of the interop assemblies, and now everything works as expected.
I have a DLL written in C# and set for COM visibility. I have it setup as a side-by-side assembly and can successfully deploy the application to client PCs registration free. My question is related to the development PC. Is it possible to compile against the DLL in a similar registration-free manner or is registration required on the development machine? I have tried adding the DLL directly though the Project -> References menu and get an error stating "Can't add a reference to the specific file." The DLL is sitting in the same directory as the .vbp file and I have tried adding the DLL both with and without the client app manifest being present.
I have tried adding the DLL directly though the Project -> References menu
That adds a reference to a type library. A type library is a language-independent description of the types in a COM component, VB6 uses it to know how generate efficient code and to provide type checking and auto-completion. A type library is the exact equivalent of metadata in a .NET assembly.
Traditionally, and the way VB6 did it, the type library was embedded as a resource in a DLL. So you are probably used to picking a DLL in the dialog. That however doesn't work so well when the DLL is generated by C#, the type library can only be generated after the C# code is compiled. You have to pick the .tlb file in the VB6 dialog. The traditional way starts with the COM component being described in the IDL language, the type library can be generated before the code is compiled so can easily be embedded in the final DLL. It is technically possible to do it in C# as well, but the build steps are very laborious and painful, you essentially have to build the DLL twice with different build commands.
The type library for a C# library is normally generated in one of three ways:
Using Project + Properties, Build tab, "Register for COM interop" option. This requires VS to run elevated so it can write to the registry. You start VS elevated by right-clicking its shortcut and picking "Run as Administrator"
By running Regasm.exe, using the /tlb:filename option. An alternative for the 1st bullet and necessary if you don't want to run VS elevated for some reason. Using the /codebase option on your dev machine is also wise to make it work exactly like the 1st bullet and not require putting the DLL into the GAC with gacutil.exe
By running the Tlbexp.exe utility, the type library exporter for .NET assemblies. No registration is done, it only generates the .tlb file.
The first bullet is the normal choice and very desirable because you can never forget to update the type library this way. It is perfectly fine on a dev machine since you only really care about reg-free deployment on the user's machine. You probably got into trouble by not doing this anymore.
Using the 3rd choice is okay and more compatible with your goals, run Tlbexp from the Visual Studio Command Prompt. Just keep in mind that you have to do it again when you make changes to your C# code. Forgetting this once and losing clumps of head-hair trying to figure out why your C# changes don't seem to be effective or getting hard-to-diagnose error codes gives you lots of reasons to consider the 1st bullet again :) You can emulate the reg-free scenario by running Regasm.exe with the /uninstall option.
At a high level, my question is:
Is everything that is supported by Mono on a Linux platform supported by Android.Xamarin on an Android platform?
More information: I am investigating the possibility of porting a complex C# application which was targeting the .NET v3.5 framework onto an Android tablet, and want to confirm my understanding of what is supported in Mono vs what is supported on an Android device.
Mono's Compatibility list does a pretty great job of explaining what features are supported in the Mono architecture. As they so clearly state, mono supports:
Everything in .NET 4.0 except WPF, WWF, and with limited WCF.
However, understanding what is supported in Xamarin for Android is not as easy. I found this topic on Assemblies, which includes a description of the namespaces supported under System.dll
Silverlight, plus types from the following namespaces: [more listed]...
The silverlight reference mentions that System.Windows.Threading is under silverlight, but this doesnt seem to make sense if I simply create a new project.
Here's an example: if I open a new mono project and attempt to access System.Windows.Threading, I cannot access it unless I include a reference to WindowsBase.dll. Moreover, I can only successfully reference WindowsBase.dll from within an "Android Class Library" Project - if I attempt to create an "Android Application" Project and attempt to reference WindowsBase.dll I receive a cryptic compilation error, pasted below.
Error 2 Exception while loading assemblies: System.IO.FileNotFoundException: Could not load assembly 'WindowsBase, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Perhaps it doesn't exist in the Mono for Android profile?
File name: 'WindowsBase.dll'
at Xamarin.Android.Tuner.DirectoryAssemblyResolver.Resolve(AssemblyNameReference reference, ReaderParameters parameters)
at Xamarin.Android.Tasks.ResolveAssemblies.AddAssemblyReferences(List`1 assemblies, AssemblyDefinition assembly)
at Xamarin.Android.Tasks.ResolveAssemblies.AddAssemblyReferences(List`1 assemblies, AssemblyDefinition assembly)
at Xamarin.Android.Tasks.ResolveAssemblies.Execute() C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets 720 2 AndoidCtmConnectionTester
So my follow up question is: Why would I get a compilation error when referencing a DLL from an Android Application project, but not an Android Class Library Project
System.Windows.Threading is considered as a part of WPF, so there no intention to make it work in Xamarin.Android.
If you want to reference .NET assembly directly, Xamarin.Android can load only few simple .NET assemblies (and with warning: "The referenced project is targeted to a different framework family (.NETFramework)" )
There is also a big chance that WindowsBase.dll is wrapping some win32 native methods, so it is impossible to run it under Android environment.
So the bad news is that you need to port your code to System.Threading classes.