I have installed ActiveMQ 5.13.0 Release on the server and trying to access the broker with C# client. I created a console application and installed Apache.NMS.ActiveMQ version 1.7.1 nuget package. When I try to access the broker:
Line 1 Uri uri = new Uri("tcp://192.168.110.136:61616");
Line 2 NMSConnectionFactory NMSFactory = new NMSConnectionFactory(uri);
On the second line it throws No IConnectionFactory implementation found for connection URI: tcp://192.168.110.136:61616/ exception.
Project's .NET Framework version is 3.5 and I also tried with .NET 4.0 and 4.5 as well. But the result is same, throws the same exception.
ActiveMQ is running on the server and I am able to access to the server's 61616 port with telnet and the management UI. I checked other similar posts but did not help to fix the issue. Any help is welcome.
Thanks.
First, be sure that your applications references both the Apache.NMS.dll and the Apache.NMS.ActiveMQ.dll assemblies in order to have access to all the implementation bits.
Then try using a URI that references the provider implementation you are trying to use via the generic NMSConnectionFactory:
Uri uri = new Uri("activemq:tcp://192.168.110.136:61616");
Optionally you can use the ActiveMQ IConnectionFactory implementation directly:
IConnectionFactory factory = new Apache.NMS.ActiveMQ.ConnectionFactory(uri);
If anyone knows what is the difference between please explain.
In my project I had used a very old version (1.1) of Apache.NMS.ActiveMQ and it came with a file named nmsprovider-activemq.config.
When I upgraded I got into the same type of problems you observed.
What I found is that NMSConnectionFactory differs from earlier versions.
Newer versions has a lookup lists of pre-configured factory URLs (to locate the right assembly and factory implementation)
The name of the assembly can be overridden by the configuration file I mentioned. However, where old versions required the configuration file to provide the full name of the assembly (including the .dll file extension) the newer versions of NMSConnectionFactory calls Assembly.Load() which will fail in this case.
Simply loading the ActiveMQ assembly yourself and instantiate its factory is less complicated, but I guess switching between various factories becomes more of a chore then. The practical result (if you only care about one type of factory) is the same however. NMSFactory's main mission is to locate the factory class of the chosen provider.
The final pitfall when upgrading this assembly is that calling .Start() on the connection object is now required.
TL;DR: Check if you have the config file I mentioned. Either edit it (get rid of the .dll file extension) or remove it completely (it probably does not contain any info not already hard coded into the Apache.NMS assembly)
Related
I have a DLL I generate from a C# project. I then register it via regasm so that the library can be used inside several legacy VB scripts.
Recently I created a new project (C# console app) that will reuse certain modular aspects of the original library, and per good programming practice it made sense to add the library to the GAC for reuse by this and any future projects.
I've found that it plays nice at first, but after the server is rebooted, the VB scripts crash and burn, claiming they are unable to create an object of one of the types defined in the library.
The fix involves removing the library from the GAC and re-registering the library via regasm.
The libraries in the registry and GAC come from the same physical DLL file - same directory and everything.
I've confirmed the existence of registry entries for the library every step of the way, which says regasm did its job.
GAC entries only exist when the library is installed, and properly disappear when it is uninstalled. They only ever appear under GAC_MSIL, where, to my knowledge, they should be.
Any ideas why this is happening?
EDIT: I did not read the fine print, haha. On the regasm documentation I just saw this: "Creates a Codebase entry in the registry. The Codebase entry specifies the file path for an assembly that's not installed in the global assembly cache. Don't specify this option if you will subsequently install the assembly that you're registering into the global assembly cache. It is strongly recommended the assemblyFile argument that you specify with the /codebase option be a strong-named assembly." I was using that switch, so I will dig deeper. In the meantime any additional insights are greatly appreciated.
I would guess you didn't renew the GUIDs and/or distinguish the fully qualified type names of the new library and when you installed it with regasm, the old entries in the registry got overwritten. Registering the old library again has overwritten the new library's registry, but as you don't use it through COM that didn't affect it and now the scripts work again.
I have been working on a library which can perform various email actions with either EWS or MS Graph.
I had great success implementing EWS because of the limited amount of dependencies required for the EWS API. However when I implemented MS Graph into the library the amount of external dependencies grew ALOT, I went from (estimated) 2-3 external dependencies to 15-17.
(By external dependencies I am refering to dependencies which does not come standard with .Net framework 4.8)
All these depedencies are installed with the nuget package manager.
While I only had EWS implemented I had no issues to get ILMerge to merge the final DLL with the external dependencies, but as soon as I implemented Graph ILMerge would no longer work.
This is a problem as the library was originally developed for use in an application called Kofax TotalAgility (KTA), but this application would only store the single DLL as a blob in its internal database. This meant that when KTA read the dll for classes and methods (KTA gives an overview of available methods to be executed along with input and return parameters) the application would fail telling me that it could not resolve "Azure.Identity.dll".
After SO MUCH STRUGGELING to get ILMerge to work, but with no luck, I yielded and tried another approach.
I decided to develop an ASP.net Core application which would expose the methods in the DLL as a REST service, this in theory was an okay solution as KTA has excellent REST service support.
This new REST service worked on the premise that controllers would have post mappings for each method, and the controller would call my library.
Having the library external would be preferred as I might need it as standalone later.
Now having developed the REST API I created some Unit tests to test the different endpoints, to make sure everything worked as it should.
These told me that the EWS implementation still works as intended, but the Graph implentation throws an error: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Identity.Client, Version=4.39.0.0, Culture=neutral, PublicKeyToken=0a613f4dd989e8ae'. The system cannot find the file specified. File name: 'Microsoft.Identity.Client, Version=4.39.0.0, Culture=neutral, PublicKeyToken=0a613f4dd989e8ae'
I held my hopes high as the missing dependency was no longer the "Azure.Identity.dll", hoping that copying the missing DLLs to the IIS Application folder (next to the executable) would fix the issue, this however did not help anything.
I have since not been able to find any other solution.
I have thought about an internal assembly resolver which would be a C# event run everytime a dependency should be resolved. I would subscribe to this event in the class contructor, so that it would be ready whenever a method was called.
This probably would fix the issue in ASP.net Core, but it would not be fixed in KTA. If KTA should load classes and methods then the library is never "instantiated", I have tried doing the assembly resolve solution using a static constructor, but this does not help.
To sum up here is a list of things I have tried:
AssemblyResolver in a static contructor
RegAsm all the depedencies needed
Putting all depedencies next to the executable
Uploading all the dependencies to KTA Store
Merging all dependencies using ILMerge and ILMergeGUI
Embedding interop types (long shot, but I am desperate)
Trying to merge only dependencies that could not be resolved
Copying gacutil from my development machine to the target machine to use that instead of RegAsm (also a long shot)
Loading depedencies directly as an embedded resource
The optimal solution I am looking for is a library that is free of external dependencies.
But I can settle for a solution to my dependency problem in ASP.net.
I hope you can help.
I am calling an old (ca 2014) COM assembly in a .NET application. The system that this application is running on has been moved from one domain to another, and apparently the COM assembly requires settings or some other values that are present in the profile, so we moved/copied profile data over to the new domain users profile. This has fixed a number of issues concerning the use of this COM assembly, but at least one still remains. It is attempting to access some file during the execution of a method, and it throws a The specified path is invalid exception.
The developer for this tool is no longer available, and what I really need is to just find out what file it is trying to access, and get that file back into the filesystem where it is looking for it. The documentation is not helpful in this regard.
I am getting the following runtime exception, except I think my case is different than the dozen or so I've seen so far, most of which are a couple years old.
Could not load file or assembly 'System.ValueTuple, Version=4.0.3.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
We had been using System.ValueTuple and ran into these common issues back when they first incorporated the library into the core language. Since then we have removed all references to the old nuget package and all projects target 4.7.
Since then we have been successfully using the ValueTuple constructs throughout our solution without any problems. Until now, I have a specific call that fails, while other calls that return a ValueTuple succeed, from within the same method. I don't know what the difference could be since all the calls use custom objects serialized across a SignalR hub through an interface like:
Task<(MyObject myobj, Guid myguid)> GetStuffd(Guid id);
I bumped all our projects to 4.7.2. I removed every binding redirect in every app.config file. Still nothing. And since other ValueTuple calls work from the same project, I don't think I'm on the right track with these kinds of solutions. Any ideas?
The problem was actually server-side and removing the binding redirect from my host service easily solved the problem.
It's worth noting that a new .Net Standard 2.0 library was the catalyst here. My call down into a .Net Standard class library is what prompted the issue. This is what was different from other calls already using ValueTuple.
Clearing the binding redirects was indeed the solution after all.
I have a service dll, which has a reference to System.Web.OData (from Microsoft.AspNet.OData.5.9.0)
The service dll has an exposed method which takes in an OData.Delta<>
This service dll when compiled is ilmerged, so it has this "version" of Data embedded.
Now the consuming application, also has a reference to the same OData, however, it comes from a corext, globalized cache.
However, when the consuming application, attempts to call the method that has an OData.Delta<> parameter, it complains that it cannot convert from ConsumingApp.OData.Delta to ServiceDll.OData.Delta.
How would I go about making sure that the parameter uses the actual proper "version" of OData.Delta so that they do not conflict?
I can't seem to find like.. a NameSpace.For.ServiceDll that would enable me to specifically target the OData.Delta that is embedded in the ilmerge
you have to install ms odata client for visual studio create a new odata client class, an add in http uri metadata de correct http. After that click on the file and run custom tool option download de latest metadata
Sorry I understood that had problems with odata schema. The error you expose, if I understood well you are using ilmerge for combine various project and reference again the library combined. I think:
you can add the namespace with a surname, for example:
import reference1 = microsoft.data;
import reference2 = ilmerge...;
so you can use them in code like reference1.class1 and reference2.class1
Hope this help you