I got a problem here:
I wrote a win32 dll project,which included WinRT libs; (i used this dll to process windows 10 packages, and it has to be in WinRT environment). and it exports some com-like interfaces (dllregister,dllreg,dllunreg..).
Then ,I wrote a win32 desktop exe,try to load this dll ,but what i got is:
ErrorCode:126. So i load this dll by Dependency Walker, and it says that api-ms-win-core-...dll can NOT be found.
but why? I can debug this dll in VS2015 with that app,but when i run that app by clicking it,which loads this dll,it returns errorcode :126?? (DLL load error??)
Related
Using Registration-free WinRT it is possible to load WinRT components inside Win32 application.
What's the process to load WinRT component from inside Win32 dll? I tried the steps mentioned as part of Win32, but winmd files are not generating the corresponding header files.
Main usage scenario is dll can be loaded any application, like electron node addon or c# app etc.,
Without any changes to application, dll by itself should be able to consume WinRT component!
Did you add a reference to the WinMD file in the vcxproj and then installed the C++/WinRT NuGet package? This should make it generate the corresponding header files that your DLL project can then consume.
Following is the solution:
Was able to fix this in weird manner i.e. not a standard way to solve this.
Our use case was to use FFmpegInteropX inside win32 dll, so that we can use ffmpeg as a source reader and use the underlying hardware decode support. Mechanism is discussed detailly in the following link:
https://github.com/ffmpeginteropx/FFmpegInteropX/discussions/275#discussioncomment-3091100
Following changes were done to use WinRT component inside a Win32 dll:
Copied the WinRT generated files from the application to Win32 dll project
Before invoking any of the api from the generated runtime class, did LoadLibrary of the specific WinRT component into the dll
Now the make the necessary WinRT component call as it was done in standard win32 application
All modules were working as expected.
Above solution was copied from:
https://learn.microsoft.com/en-us/answers/questions/924996/how-to-consume-winrt-component-inside-win32-dll-pr.html
It's not a straight forward solution, also not sure if MS has any plans to add support for WinRT component inside dll project, if such support comes up then this may not be needed.
I am using JSON.Net to get my Console application to translate sentences with Google Translate. My code fully works fine with absolutely no errors when I run it in Visual Studio. But when I take the .exe out of the "[project_name]\bin\debug" folder and copy it to the desktop to run it returns the following exeception.
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The system cannot find the file specified....
I noticed that in my "[project_name]\bin\debug" folder there is the .dll file that I am using, but not only this, I am also using a .dll that I referenced somewhere else.
When I drag this .dll file with the exe onto the desktop and run it, it works. How do I make it so that I don't need the .dll with the .exe on the desktop? Or is this something that is necessary? I am sure that I have referenced everything properly.
If your application makes use of a library then that library has to be there to make use of. There are basically two ways to make libraries available to .NET applications. The library needs to either be in the same folder as the application or it needs to be installed in the GAC (Global Assembly Cache). The GAC is a common location for libraries so that multiple applications can access them. Unless you intend to ensure that JSON.NET is installed in the GAC on every machine you plan to run your app on, you need to make sure that the library is deployed along with your app. This is how applications work. There is no magic solution.
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.
Running under Win7 SP1 with VS2010 and Microsoft SDK v7.0a. If I create a VS2010 project for a Win32 console application, a CreateInstance on a regsvr32.exe registered COM DLL succeeds. If I create a VS2010 project for an MFC GUI, the identical CreateInstance fails with E_NOINTERFACE. Have tried both Unicode and multi-byte, works both ways for Win32 console application, fails both ways for MFC GUI. How is this possible?
If I F11 through the Win32 console application, I eventually see the CreateInstance get to a QueryInterface on IUnknown [which succeeds]. If I F11 through the MFC GUI, it never gets to the QueryInterface.
I've seen some talk about ADO versions/upgrades being relevant, but here is one system that succeeds for Win32 console application and fails for MFC GUI. How?
Update: I was mistakenly allowing the WinDDK comip.h to be used instead of the VS2010 comip.h. But even after correcting that, the problem remains.
Also discovered that the same MFC GUI project and source compiled on a 64 bit machine does NOT fail. Only my 32 bit machine does. Both get to QueryInterface in the CreateInstance call stack, but the 32 bit machine returns failure, whereas the 64 bit machine returns success.
Courtesy of MSDN tech support, I was enlightened that MFC GUIs do not support the "free threading" that COM requires.
I have one problem in vb6. I created a .tlb file in VB.net 2005 by adding Com class to project. I built the project, I got .tlb file and .dll files while building project, i selected "Register for Com interop" from project properties and built. It registered autometically and I can use created .tlb file in that PC in Vb6 working fine. if I deploy application to another PC and run I am getting "Error 429 ActiveX Component Can't create object" run time error. What I need to do? Please help me as soon as possible. I can't deploy the application to client due to above error.
one possible solution is to install .net frame work on client pc i never want to install .net framework any other solution will be most appreciatable.
If you've created a DLL in a .NET language (such as VB.NET), the target computer must have the .NET Framework installed in order to use the DLL.
This a hard and fast requirement, irrelevant of how you're utilizing the DLL, whether from a VB 6 application through COM interop or otherwise. It is also a hurdle you'll have to jump over first, before you worry about things like registering COM components, as Uday's answer suggests.
If you don't want a dependency on .NET, you need to use another environment to create the ActiveX DLL; either C++ or VB 6 are possible choices.
One option may be that, while deployment, you need to register that .tlb file in System Registry using regsvr32 command in command-prompt. Generally static libraries does not work until they are registered with System Registry.
You might have seen many programs register components during installation like 'Registering Type Components' or 'Registering COM Components' (for those who do networking especially). Those components are nothing but native COM dlls and tlbs.
so when creating deployment project, add some scripting login to register thode dlls and tlb to System registry using:
regsvr32 <path to tlb/dll>
you have to recursivey call this command for every dll/tlb you want to register with system. For example, if you have 4 dlls and 2 tlbs then you have to call it 6 times providing the path of dll and tlb one at a time.