Given the changes in windows platform of recent and C++Winrt being its own platform , what is the latest greatest way to bidirectional introp with C# from c++ Winrt project.
Currently there is no DLL project template for Winrt, is that cause the future is Run-time time components, and we should not be expecting winrt dll project.
is there a winrt example that shows implementation and consumption of c++ winrt runtime component.
Can i still use pinvoke from c# into c++ winrt project, any perf info regards pinvoke compared to runtime component.
what about reverse pinvoke, given there is no dll project type for winrt
Any winrt c++ specifics regards marshalling
What about hosting managed context API provided by dotnet, is there equivalent accessible form Winrt::Windows. To be used by C++ Winrt app calling C# API. I think the class name in .Net is ClrRunTimeHost, is this in winrt::windows.
Cheers
Related
I make a UWP program and I have to get data from a Oracle database of my customer. My customer gave me a dll which he made. I tried and found that made by .net framework of 4.6.2 so that UWP do not support it. I suggested him rewrite the dll by UWP, but he refused that. So I have to find a way to make it works in UWP.
I googled and found that if I make a .net standard dll for the bridge between UWP and .net framework that I can make it works in UWP.
Finally, I made a .net standard dll, in the .net standard I reference the dll my customer gave.
But after I debugged my .net standard dll, all code I wrote works without error, but the dll my customer gave threw an error:
"The type initializer for 'OracleInternal.Common.ProviderConfig' threw an exception."
I wonder if there is something wrong with the dll of my customer. However,it is so strange that if I reference his dll in winform, all is OK, but only in .net standard it crashed. What's more, the code what I wrote in winform/.net standard is the same, only declare a class and run a void, just two-line code.
My customer knows nothing about UWP and I also know nothing about Oracle.I don't want rewrite whole project by WPF just for this, that's such a huge work!
Would you please teach me what's wrong with that and how to solve my problem. Thank you.
I wonder if there is something wrong with the dll of my customer.
In short, there's no wrong in your customer's .net framework dll. You just misunderstood the .NET Standard. Your .NET Standard library worked in winform, that's because your .NET Standard library adds reference to your customer's .net framework dll. This .net framewrok dll works well in .net framework applications, but it doesn't mean that the APIs in the .net framework dll are supported in UWP, even if you've used your .NET Standard library to wrap it. I suggested that you could read Introducing .NET Standard for more detailed information.
For your question, if your customer does not want to rewrite their dll and you're also not able to write a library to make it work in UWP. You could make a WCF. In WCF, you could directly add reference to your customer's dll. Then, you could use this WCF service in your UWP directly.
I have one PC with Microsoft Visual Studio Community 2017
Version 15.2 and it has a project template for Class Library (Portable).
Another PC with Version 15.3.1 has a template for Class Library (Legacy Portable). Are PCLs now legacy ?
Any current news on what I should be using instead ?
Well, "should", I won't say that without seeing exactly what you're doing but yes, PCLs are now "legacy", the new way is .NET Standard and .NET Core.
Please note that legacy does not mean "will stop working" so there shouldn't be a need to do anything as of yet.
To figure out which kind of .NET Standard version you want to target to get-out-of-legacy, you can consult the compatibility list on the .NET Standard web page.
Specifically, you likely want to consult the other matrix on the same web page, the .NET Implementation Support matrix and figure out which platforms you want to target, then create a "Class Library (.NET Standard)" project targetting the highest .NET Standard version you can get away with.
In almost every text about the new WinRT API I came to statements like "WinRT is the new API for Windows and replaces the old Win32 API". Since WinRT aims the development Windows Store apps, this statement to me does not seem to hold true.
There are lots of applications I just can not imagine to be done with WinRT (e.g. Microsoft Office, Adobe Products, 3D Designer Programs and even Visual Studio). These applications still need the functionality of the Windows API (aka Win32).
So why is it so often said, that the WinRT API replaces the Windows API?
This has kind of changed, recently due to a couple reasons, but here's the rundown of why you want to use WinRT over Win32 in current Windows application development (circa 2017):
WinRT is leveraged by UWP apps
Win32 apps can be converted into UWP apps using the Desktop Bridge
Windows 10 S requires all apps to go through the Windows Store
Ergo, using WinRT will invoke less time spent converting projects and code for the new Windows 10 S Store-only application paradigm.
In regards to WinRT vs. Win32API vs. .NET, both .NET and WinRT are partially built with Win32; IIRC, they use subsets of it. At least that's what was communicated back in 2012 from ArsTechnica in Peter Bright's article, "Turning to the past to power Windows’ future: An in-depth look at WinRT". That's where this stack chart comes from, or at least it was used there:
I'm not sure if it's often said that the Windows Runtime (WinRT) API replaces the Win32 API. It's not something Microsoft is saying. In many ways WinRT tries to learn from the failure of the .NET Framework to replace the Win32 API. That includes Microsoft not trying to push WinRT as a replacement, but merely a new way of doing things.
There isn't actually much of a reason why the applications you mentioned couldn't be be implemented using the WinRT API. The new API includes a lot of the functionality of the old. You can write WinRT applications in C++ and the resulting applications are native executables, not managed ones. It's even possible to use a subset of the Win32 APIs.
While Adobe has little to gain by porting its applications to WinRT, expect Microsoft to do so. They rewrote most of Visual Studio to use the .NET framework. If anything the WinRT API makes it practical to implement much more of it the new environment.
I have a code base of native C++. Recently I incorporated a Windows 8 tablet into the system that we deploy to.
I have a .NET managed DLL that accesses the Tablet orientation sensor. This managed code is wrapped by an unmanaged class that I can access from the native C++.
The problem is that I cannot run and debug the code on my Windows 7/VS2010 box without getting an Access Violation at the outset. No breakpoints are even hit before the exception.
Is there a way to ignore the managed DLL while debugging on the Windows 7/VS2010 box?
Delay loading is your friend. Read the MSDN documentation, starting with Linker Support for Delay-Loaded DLLs.
I have a very basic question. I have developed a com dll to be used from Access vba. Works great on my development machine. On a test machine I get the
"error -2147024894 (80070002) Automation Error
System can't find the specified file"
msg when I run the Access application.
When in design view the dll is referenced and all the objects and properties show up in the vba ide.
I am wondering if I am using the wrong regasm to register the dll? I develop on a 64 bit machine using VS 2010.
I compile the dll to run on x86 in Framework 3.5. Should I use the framework v2. o.50727 or Framework\v4.0.30319 to register the dll. Not clear to me what the difference is. Is the version used determined by the development version of VS or the .NET version you compile in? Is one used for 32 bit and the other for 64 bit?
I have been fighting this for 2 days and have made some headway but can't get the Access routines to actually set an instance of the dll in runtime.
Thanks in advance for any assistance.
If you are compiling under v3.5, you should use that regasm. However, I think you might need to add the /tlb and /codebase switches to generate the type library that you can use in vba apps. You can then ref the .tlb file and you should be golden.
You need to register your COM dll using regsvr32 for referencing it from VBA.
VBA uses COM DLLs. You would have to use C++, not the .Net framework.