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
Related
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.
Hi guys im just new in C# i came from a PHP background. I'm working on a RFID project which has RRU1861CSharp.dll which is dependent to basic.dll. I am able to add reference RRU1861CSharp.dll but when i'm trying to add reference basic.dll it says:
"basic.dll could not be added please make sure that the file is accessible, and that is a valid assembly or COM component".
I cant post picture sorry i don't have enough reputation.
You don't need to add the dependencies of RRU1861CSharp.dll to the project. It sounds like it's not a .NET assembly which is why you can't; however, you do have to ensure that it is installed on the final client/server where your app will run, along with all the other dependencies of RRU1861CSharp.dll.
It also has to be accessible on you dev machine to run the app from VS.
However, it is not a reference: References are only the things your app needs directly.
I have a C++ DLL Library. I'm testing the DLL with a C# Project with NET Framework 4.0. In the C++ DLL I'm using some libraries, like POCO, Boost, ODBC, SQLite, SOCI...
It was doing great until I decided to replace the SOCI interface with the POCO one to reduce the number of libraries loaded in the library.
I compiled the PocoData, PocoDataODBC and added them, together with the headers, into the project. The project compiles OK, creates the DLL, and the DLL passes the Dependency Walker tests.
But something strange happens when using the DLL from the .NET Project. The app just closes when executing the DLL methods that contains the Poco::Data part to connect with the database.
There is no exception or error thrown. Not even "application just crashed" from windows. It just stop running and the Visual Studio returns to normal just like if it ended correctly.
I isolated the error and it's enought with any use or call inside the PocoData library to do this error. I can use the library until it tries to use a method that has any call to this. For example:
Session session("ODBC", conn);
Or even this alone:
Poco::Data::RecordSet rs();
So every time the C# calls a method that contains anything from the Poco::Data in the DLL it fails.
Any idea what can be happening?
Windows events log something when the app makes the error, I don't know if it's relevant. It raises two events, the first one is a system hour change between same value (strange), type: Kernel-General.
The second one (about 10 seconds later) is Service Control Manager level Information:
Service Windows Error Reporting Service entered in running state.
Edit3: Sorry for the constant edits, I'm sure there's a law which states progress is only made once you've publicly requested a solution.
I've opened the oracle assembly in Reflector. The assembly includes a reference to the both the v1.0.3705 mscorlib AND the 2.0.0.0 mscorlib...
It also references a Common.Logging assembly which targets the v1.0.3705 runtime.
This strikes me as at best odd. Anyone ever seen something like this before?
Edit2: Ok, created a WPF application against 3.5. Referenced my API library, added a line to call the code that declares a variable of an interface type declared in the Oracle library and it all works.
So the problem only occurs with Framework 4 applications. This makes a certain amount of sense to me as 3.5 is essentially 2 with some extra libraries. But I'm now confused as to why I can reference a 2 assembly in my 4 project and use its types, just not this Oracle one, and with an unhelpful error.
Edit: Seems to be an issue with the framework version. I'm suprised I haven't encountered something like this before.
Here's the new situation:
Added new Windows forms application set to Framework 2.
Added reference to Coherence DLL in GAC (It never appears in references under assemblies, is that bad?) using path.
Added button with line "INamedCache cache;" That's it. compiled and run. All works fine.
Step 2, remove reference to coherence, add reference to my original API. Compile, all works fine. Remember the API is just running the line of code above.
Now, if I add a reference to the Windows forms application to my WPF application, and create a Form1, again, all the IntelliSense works, but when you compile it gives a "type or namespace not found".
Again, remove the "INamedCache cache;" from the Form1 in the forms application (still referenced by the WPF application) and it all compiles again.
So my WPF Framework 4 application will consume my framework 2 windows forms application (with Forms 2 reference added of course) but if that forms application contains a reference to the oracle library AND declares a variable of an interface type declared in that library. boom, instant failure.
Original post here:
Visual Studio 2010.
I have a WPF windows app project and a class library. The class library references Oracle's Coherence for .NET assembly. The class library has one class with one method which declares a variable of an interface type.
The WPF application has a button which calls this method. IntelliSense works fine.
When I try to compile I get the old "The type or namespace named 'WhyAreYouNotWorking' could not be found" error. I have a demo project which does run, I've copied the references from one to the other with no luck. I've added references to any supporting assemblies.
Also
public void Test()
{
INamedCache cache;
//CacheFactory.SetCacheFactoryConfig("coherence.xml");
//CacheFactory.SetCacheConfig("cache-config.xml");
//CacheFactory.SetPofConfig("pof-config.xml");
//INamedCache cache = CacheFactory.GetCache("ians-cache");
//Console.WriteLine(cache.CacheName);
}
Above you see the one method in my class lib. This lib will compile happily with all those lines commented or uncommented. The WPF application will only compile if I rem out ALL the lines.
So the problem here is the WPF application will not compile with a reference to the class library, if the class library includes code contained in the Coherence Oracle .net assembly.
I'm baffled. Slightly embarrassed and baffled :)
Hmmm, copy to output directory in the reference properties maybe?
Gotcha.
WPF 4.0 application had defaulted to ".NET framework 4 Client Profile". Switching it to ".NET Framework 4" resolved all the problems.
Still don't fully understand why.
I tried to run Redis-Sharp test program. It sets the string length when I set some key,value (both strings). And while reading the data it throws exception.
I then moved on and tried ServiceStack.Redis and after adding library reference it properly shows the properties of RedisClient etc but when I try to build it throws an error no library reference found. Can anyone help me get past this step and actually see some test programs running proper commands on Redis server ?
Regards,
Lalith
When a new project is created in Visual Studio 2010 the Target framework (on Application tab of project properties) is set to .NET Framework 4 Client Profile; changing this to .NET Framework 4 resolves the RedisClient build problem.
I'm the maintainer of the ServiceStack.Redis client - can I ask which build are you having problems with? i.e. what build references were you missing?
I've currently in the process of moving to GitHub (which is now the official project site of the open source project).
So from now on the latest source code and binary releases will be available here:
https://github.com/mythz/ServiceStack.Redis
In GitHub the Redis Client is now a self-contained, top-level project so you should be able to build without any problems.
Older binary releases (and source code) should still be available from the old project site:
http://code.google.com/p/servicestack/wiki/ServiceStackRedis
Hope this helps,
-Demis