I have strange problem with receiving collection from Microsoft Graph.
My goal is to create add-in as DLL for another system, which process MS Graph collections.
I use code as follow:
var drives = graphClient.Sites[siteId].Drives.Request().GetAsync().Result;
return drives.Count;
In Visual Studio 2019, within Unit Test Project, it work fine without errors.
Problem appears, when I use the DLL in destination system. There the same code throw following exception:
-2146233088 | Could not create an instance of type Microsoft.Graph.ISiteDrivesCollectionPage. Type is an interface or abstract class and cannot be instantiated
Have you any idea, why Graph SDK as Add-in doesn't automaticly deserialize received objects?
It work fine if receive one class, not collection.
Work-around is by use HttpRequestMessage / HttpResponseMessage, but it's so friendly as above.
I will be grateful for your help
Sounds like a dependency(.net framework, libraries) is missing at the destination system. Make sure it has the necessary dependencies installed. Always use the latest NuGet package, make sure the dependencies exist in the destination system.
Related
I'm trying to write a C# project that makes use of Bruel & Kjaer 2250 SDK. The SDK installer installs a VisualStudio 2015 Windows Form C# project that I'm able to build.
The next step for me was to create a similar project from scratch, so trying to do this and following litterally the BK instructions what happens is that I'm not able to create an instance of of class RemoteAPI in BK.BasicEnv.Application namespace.
I get an exception that tells me these informations:
An unhandled exception of type 'System.NullReferenceException'
occurred in BasicEnvRemoteAPI.dll
Additional information: RemoteAPI - Construction: No Instance of
EnvOfficeModel.
The constructor call is very simple:
private RemoteAPI api;
...
api = new RemoteAPI();
So the ctor of RemoteAPI is failing because an instance of EnvOfficeModel is missing to it,
I've googled a lot and made some tests but the result is always the same for my own project while the B&K example is correctly starting and is able to create an instance of the RemoteAPI class.
I also tried to compare the two projects and I'm not able to find a different setting, then I tried to search the B&K installed files and the registry for some hint about the possible causes of this behaviour, but no way ....
If some of you had the same problem and could perhaps drive me to the correct information to solve this problem will be a great thing.
I know that also a REST interface is available to communicate with BK2250 but I would like to use the native communication driver if possile.
Thank you and kind regards.
I encountered the issue today,
Verify that you imported the dll in the project correctly (Should appear under References if not it's probably the second issue)
Verify that you are using the .NET Framework and not the .NET Core
I managed to get it working with a Windows Form application using the .NET Framework 4.7.2
I'm writing a C# application that accepts plugins. The way I accomplished this is as follows:
In my solution, create a project that contains a single interface that defines the expected methods of a plugin class.
In the main application, add a reference to this project containing one interface.
Add a third project to the solution which represents a plugin. This plugin also has a reference to the interface project.
In my main application, I scan a plugins folder for files matching a given filename (plugin_.dll). If such files are found, I load the assembly and then use reflection to look for any class that implements the interface. For any such class, I add an instance of it to a List<IPlugin>. The app then has access to all the plugins via this list.
This works great and I have successfully written a couple of very simple plugins.
Here's where I'm struggling:
When I want to test the plugin, I have to first build the solution and then manually copy the built plugin into the correct location which the app scans. I know I can probably automate this by adding a post-build command though.
More importantly, is there a good way to actually debug the code in the plugin? (single-step, exception breaks, etc.) Right now I simply run the app and see what happens. I use extensive Console.WriteLines if I need to trace something. It's far less productive though than using VS's debugger.
Less important at this particular point but could be a thing down the road: how would someone else debug the plugin? More specifically: if I start a new VS solution and make a reference to the interface assembly, is there any reasonable way to debug the code in my new plugin?
Situation
I run a build system that executes many builds for many project. To avoid one build impacting another we lock down the build user to only its workspace. Builds run as a non privileged users who only have write ability to the workspace.
Challenge
During our new build we need to use a legacy 3rdparty DLL that exposes its interface through COM. The dev team wants to register the build(regsrv32.exe) but our build security regime blocks this activity. If we relax the regime then the 3rdparty DLL will impact other builds and if I have two build which need two different versions I may have the wrong build compile against the wrong version (a very real possibility).
Question
Are there any other options besides registration to handle legacy DLLs which expose their interface via COM?
Thanks for the help
Peter
For my original answer to a similar question see: TFS Build server and COM references - does this work?
A good way to compile .NET code that references COM components without the COM components being registered on the build server is to use the COMFileReference reference item in your project/build files instead of COMReference. A COMFileReference item looks like this:
<ItemGroup>
<COMFileReference Include="MyComLibrary.dll">
<EmbedInteropTypes>True</EmbedInteropTypes>
</COMFileReference>
</ItemGroup>
Since Visual Studio provides no designer support for COMFileReference, you must edit the project/build file by hand.
During a build, MSBuild extracts the type library information from the COM DLL and creates an interop assembly that can be either standalone or embedded in the calling .NET assembly.
Each COMFileReference item can also have a WrapperTool attribute but the default seemed to work for me just fine. The EmbedInteropTypes attribute is not documented as being applicable to COMFileReference, but it seems to work as intended.
See https://learn.microsoft.com/en-ca/visualstudio/msbuild/common-msbuild-project-items#comfilereference for a little more detail. This MSBuild item has been available since .NET 3.5.
It's a shame that no-one seems to know anything about this technique, which to me seems simpler than the alternatives. It's actually not surprising since I could only find just the one above reference to it on-line. I myself discovered this technique by digging into MSBuild's Microsoft.Common.targets file.
There's a walkthrough on registration-free COM here:
http://msdn.microsoft.com/en-us/library/ms973913.aspx
And excruciating detail here:
http://msdn.microsoft.com/en-us/library/aa376414
(the root of that document is actually here: http://msdn.microsoft.com/en-us/library/dd408052 )
Also, for building in general, you should be able to use Tlbimp or tlbexp to create a TLB file that you can use for building, assuming the point of registering is just to be able to compile successfully, and not to run specific tests.
Installation tools such as Installshield can extract the COM interfaces from the DLLs and add them to the registry. It can also use the self-registration process of the DLL (which I believe is what regsvr does), but this is not a Microsoft installer best practice.
in .NET COM is normally done thru Interop in order to register .DLL in .NET they are called Assemblies and that can be done several ways.. by adding references via VS IDE at the project level, or writing code that Loads and unloads the assembly.. by .Config file that haas the reference to the assembly as well as the using of that reference within the project... GAC.
If you have access to the 3rd party .DLL's you can GAC them, and reference them in your project
you can add a using to your .cs file header as well as add the reference to the project by right clicking on reference --> add Reference ...
you can also do the above step as well as set the copy local = true in the properties for that .dll.. I hope that this gives you some ideas.. keep in mind that .NET assemblies are Managed code so there are several ways to Consume those 3rd party .DLL's using other methods within C# like LoadFromAssembly ect..
Thanks for all the help.
We changed from early-binding to late-binding because we never really needed the DLL at compile time. This pushed the registration requirement from the build server to the integration test server (where we execute the installer which handles the registration). We try to keep the build system pristine and have easy-to-reset integration systems.
Thanks again
Peter
I'm trying to use COM functions exposed by an EXE. I've created a C# project using Visual Studio 2010 (on a windows7/x64 machine) and added the reference to that EXE, then set the Isolated flag to true. When I build the solution, I get errors for each of the classes that it exposes.
Problem isolating COM reference 'FNCClient11Lib': Registry
key
'HKEY_CURRENT_USER\SOFTWARE\CLASSES\CLSID{e49b30c9-6d7e-48f5-91da-f2f0414c6a13}\InProcServer32'
is missing value '(Default)'.
These entries don't exist in the registry in that location but DO exist here (below)
HKEY_CURRENT_USER\Software\Classes\Wow6432Node\CLSID{E49B30C9-6D7E-48F5-91DA-F2F0414C6A13}
Is there any way I can point this to the right location in the registry when building?
Can I reference an EXE? All the examples I've seen so far reference DLLs only.
This problem occurs when the type library contains classes that are marked as 'uncreatable' in the COM interface. You can check this by using the OLE/COM Viewer (as Admin), navigating to the type library that causes the problem, opening it and look up the CoClass definitions. If the one using the reported uuid is declared 'uncreatable', you got it. Also, in the VS object browser, these clases don't expose a constructor in the interface.
My solution was to rebuild the COM component with a public constructor for these classes but of course this is only possible if you have the sources.
Finally, there may be other reasons for this symptom though ...
I have a problem with getting above exception. I have a relatively simple structure separate in two dll.
First one contains a IEntityService, IEntity, with basic implementation. Second one contains the actual implementations as well as interfaces. so there is a IMachine service which implements IEntityService and MachineService which implements both IEntityService and EntityService. Similar situation happen for a Result collection( entity plus service). Additionally the service(Machine and result) are partial classes/interfaces where one of the class is auto generated.
Now in one of the ResultMachine I am trying to get a machine and in a case it do not exists I am creating it and saving. However when I am trying to save I got the "Method not found" when trying to access a saving method from a EntityService class. However if I wrap EntityService.Save method in a MachineService it is working without any exception.
Edited:
The code is not required. THe resolution was to re-link the reference. What was misleading for me that my dll is not in GAC, it is linked with VS. What is more it is not strongly signed, the only difference is version number.
We have got this error a few times, you can recreate the problem as follows:
Created project with 2 dll's (say a program dll and a test dll)
deploy program dll to GAC
Add new method
Create test to test the new method
build solution
run test (not in debug mode)
You will now get the method missing exception. The reason is that it is using the old version of the dll that is in GAC and does not have the method.
Some times it uses a cached version of the old dll, IISreset can help.
In your case check for any old versions of the dll.
My first instinct would be to check to make sure the assemblies contained the classes with the missing method. I suppose its possible that the assembly didn't get updated immediately?
When referencing the "same" type from different assemblies, make sure you are loading everything via the same path. Otherwise, identical types can actually be treated as if they are different.
See this article for more: Fusion Loader Contexts - Unable to cast object of type 'Whatever' to type 'Whatever'
This happened to me when I went in and tweaked my build settings to output to /bin/Debug rather than to just /bin in a case when I was also using IIS to host the site from the dev folder.
You need to have the binaries in the same folder as the service, in my case, and the tweak left old versions in the bin folder and put subsequent builds into the /bin/Debug folder (and /bin/Release).
Either keep the settings as is and have a post build action to copy the bits up one level, have different IIS applications for debug/release, or deploy to another folder altogether. The latter is probably most "correct" but for my purposes I just realized after much wheel-spinning, that I had different versions in the service's folder. HTH.
In my case I just deployed on a machine with .NET 3.0 (Windows XP) while the compile target has been .NET 3.5.
This error message is really not helpful.
Problem has been usage of DataContract from System.Runtime.Serialisation.