I want to use a .NET Framework assembly in UWP (side loaded app). I know that it's not possible in any easy way, since UWP is targeting .NET Core.
I'm trying to create a Brokered Windows Runtime Component as explained in this article.
However I have issues:
I can't use any templates from the market, because they are for Visual Studio 2015 and I'm using Visual Studio 2017
I can't open the sample projects, because Visual Studio 2017 says that the projects (those with edited csproj files) are not compatible with that version of Visual Studio 2017
The post-build script from that article uses winmdidl however it's not in my PATH so I have to put the full path "C:\Program Files (x86)\Windows Kits\10\bin\x86\winmdidl" (don't know if that's an issue)
The winmdidl command returns an error error W1005: Exception Unknown exception
Additionally I have two questions:
The samples and article uses a C++ "Proxy" project, can I just write the logic in C# in the brokered component without using any C++ code? (I just need to be able to call some methods from UWP which are defined in a 3rd party .NET assembly)
Since the "Brokered Windows Runtime Component" method to call some code in .NET Framework seems cumbersome, maybe it's better to write some Windows Service or some other form of a REST service and communicate with it through localhost? That's a way I already use to communicate with some 3rd party tools on the machine. Is the performance and complexity in favor of the brokered component approach?
With Desktop Bridge features you not longer need the Windows Runtime Brokered Components. See this page for more information:
https://developer.microsoft.com/en-us/windows/bridges/desktop
I guess this sample using the AppService will help you to solve your scenario
Related
I've a Win32 application written in C# via Visual Studio 2015 and I want to make it portable in order to avoid the installation of .NET framework everytime I deploy my application to clients.
I read this article: the key point of making portable apps seems the use of mscorlib.dll
This method doesn't work, at least for me, despite my effort. I must presume this is not the real way to build an application as portable...?
What are my other options in Visual Studio? Should I rethink my entire application to avoid the use of NET?
Portable applications and packages still require .NET, but in a way you are not using the entire subset available in .NET, which makes it portable among different platforms (Windows Phone, Universal Apps, etc.).
As far as I know the only option you have to overcome the dependency on the .NET Framework, is by compiling your assembly in 'native', which will include all code necessary to run the app on its own.
I have solution with mixed projects: C#, native C++ and CLR/C++ (this also requires some external DLLs). When I used default settings of VS 2012 and targeted for .Net 4.5 it worked fine. But then I had to downgrade it to .Net 4.0.
I succeed by building solution only for 32-bit and forcing C# main project to be built for 32-bit also (usually C# is used for "Any CPU").
With such settings in runs fine on 2 computers out of 3 I have for tests -- meaning on it fails. It claims it cannot load CLR/C++ project or one of it dependencies.
So my problem is how to run it or at least to know what failed exactly? From the list of installed programs I can see that on working computer I have either .Net 4.5 Multi-Target or I don't have .Net 4.5 at all (only 4.0). On computer which fails I have .Net 4.5 (period). So maybe my program tries to load some assemblies from .Net 4.5 instead of 4.0? But that is just guessing.
Question -- how to diagnose such twisted solution and how to fix it?
Install .Net framework 4.0 multi-targeting pack
Check references (including NuGet, if any)
When I encounter a similar problem I usualy check the following:
Do you have Visual Studio installed on any of those three machines? I guess it's installed on the two where your application is running. If so, I'll extend the list later.
Check the target of the C++/CLI project - it should be Win32 if you build for 32-bit.
Run the application without Visual Studio, wait until it fails and go to the Event Viewer to look for some usefull information there.
Get Process Monitor, run the application without Visual Studio, wait until it fails, stop monitoring and filter the list by the application name and failed operations and look there for some usefull information.
I did look at the following question, however, it doesn't resolve my issue.
- Unable to register DLL using Regsv32 - error "Dll was loaded but the entry-point DllRegisterServer was not found"
Unable to register DLL using Regsv32 - error "Dll was loaded but the entry-point DllRegisterServer was not found"
The problem I am facing is that a new DLL created w/ C# has to literally work within a legacy POS system running in Windows XP .NET 4.0 that was originally created with Visual Basic 6.0, which automatically created all of the proper entry-points (such as DLLRegisterServer) within the DLL assembly. However, these ActiveX COM entries, since they are no longer used, are not created with C# in Visual Studio 2012/2013. So, my question is, How can I create a Windows XP .NET 4.0 (VB backward compatible) ActiveX COM DLL with C# in Visual Studio 2012/2013, to replace the original VB DLL ? Can these entries be entered manually (& successfully compiled) in the C# DLL (i.e., using ???.??? STDAPI DllRegisterServer(void) { return true; }) ?
Your terminology is a little confusing: there is no such thing as "Windows XP .NET 4.0", but it sounds like you want to use .NET 4.0 on Windows XP. That would be OK. Note that your POS must be running Windows XP SP3. Note that .NET 4.5 and above are not supported in Windows XP. Your new DLLs must be compiled under .NET 4.0 or earlier. There are special complications if your POS software already uses .NET for anything else. I'll assume here that you are using .NET 4.0 and that the POS doesn't otherwise depend on .NET.
You do need to install on the POS machines an appropriate version of the .NET runtime (the version under which your DLL has been compiled is the best choice). But after that - yes, of course RegAsm will allow you to register a COM DLL (not RegSvr32 however; RegSvr32 doesn't know how to register a .NET DLL). As I mentioned in a my previous comment, the details in the registry will necessarily be different from the details for the VB6 DLL.
The installers for the different supported .NET runtimes are available from Microsoft. There are two options:
The ".NET 4.0 Client Profile installer" is currently available here:
http://www.microsoft.com/en-us/download/details.aspx?id=24872
The "Full .NET installer" is currently available here:
http://www.microsoft.com/en-us/download/details.aspx?id=17718
If you can help it, you want to compile your DLL using the ".NET 4.0 Client Profile" option, which is a subset of the whole runtime with only the most commonly used features. The Client Profile is significantly smaller. You will know immediately if your application is compatible with the Client Profile simply by trying to compile it with that option. If you are using something that is not included in the Client Profile, your DLL will fail to compile. In that case, try first to see if you can accomplish the same functionality without using the non-client-profile feature. If you can't, then use the full runtime.
Now the hard part: you don't specify if your DLL exposes a bunch of custom interfaces, whether it only consumes interfaces declared by the application, or a combination of both. You also don't specify how the POS software knows about your DLL and whether it uses Automation (IDispatch) like VBScript would or "custom" interfaces, and you don't say who declares the interfaces. Setting up the appropriate interfaces in C#/VB.NET can be a tricky problem because VB6 doesn't exactly make it easy to look at the details.
You can pull the most critical information from the existing DLL by registering it and looking at the resulting classes via the "OLE View" tool. The rest of the details will depend on how the main POS application uses your DLL. The full details of what to do can be complex and are well outside of the scope of any one single answer in Stack Overflow.
So basically you are trying to create dotnet based COM component. Set your project property as COM visible and Register your assembly using Regasm
regasm myDotnetCOM.dll
OR
regasm /codebase myDotnetCOM.dll
Now you can use CreateObject for this COM component.
I am trying to make a setup for a C# application in .NET 3.5.
The application runs an other application which was compiled for .NET 4.5 and uses some DLLs. I want to add this application to the application folder in the setup.
I can't add the DLL's to the setup as a file, there is an error popping up. ("The operation could not be completed")
If I add the DDLs to the project folder and then use them as content, I get an "Unrecoverable build error" when I create the project.
How am I supposed to add these DLLs? I do not care how, but I need them in the project folder.
Thanks.
PS: I am using the standard setup for VisualStudio 2008.
With Visual Studio, when you add your external DLL as a reference in a project, it will automatically be added to the setup.
First of all, isn't there any way to find an earlier version of the assembly targeting .NET 3.5? Or if you have access to the source, remove/change the .NET 4.5 specific code and recompile?
Otherwise, you can try to wrap you dll around a COM interface, as described here. This article targets .NET 4 dll used with .NET 2.0 but the mechanism should still work in your configuration. I have used it successfully myself for 2.0/4.0 interop.
Here is another trick you can try.
Consider that in either case you will need .NET 4.5 installed on target computer, in order to work. So you can move your project from 3.5 to 4.5. I understand that you use VS2008 which doesn't have .NET 4.5, but you can use express (free) edition of Visual Studio from here -> Microsoft Download Page
I solved this problem using a simple trick:
The errors came only from the DLLs written in .NET 4.5. The executable (.exe) did not cause any errors. What I did is to package all the DLL's into the exe using the ILMerge tool.
Then I added the .exe file to the library and everything worked like a charm.
ILMerge download site (Microsoft)
for strict constrains in my scenarios, I have very few room to install my application, and .net framework is not installable (any version).
If the application is really simple (more or less), it is possible to create an application in visual studio (in c#) with no dependendency from the .net framework?
Thanks!
Short answer: NO.
There is no way to create a .NET application without any framework.
It is possible to compile a C# app such that it has no dependencies on any of the built-in .NET types & libraries, by using the /nostdlib switch (see http://msdn.microsoft.com/en-us/library/fa13yay7.aspx). You then need to supply your own System namespace.
However, this doesn't remove the need for the .NET framework on the target machine if you use the standard C# compiler. As well as containing the built-in types, the framework also includes the JIT IL compiler, the CLR extra, which all .NET executables and dll's are reliant on.
There are ways of compiling C# code such that it doesn't need the framework though. The Xamarin product for example (http://xamarin.com/), supports compiling C# code to native iOS apps, which are wholely independent of the .NET framework. I'm not aware of any equivalent for "desktop" OS's though.
Writing, compiling and running a C# program without .Net means running a special C# compiler that produces native code instead of managed code. I think such a compiler exists from WinRT for mobile phones, which uses COM instead of .Net (And C++/CX instead of C++/CLI). Code it produces does not depend on the .Net Framework, but does depend on the WinRT runtime.
You may create mono GTK# application and then use mkbundle to generate independent executable. You can use Visual Studio to build your logic and use Xamarin studio to build GTK# GUI. For more information about mkbundle see this and this.
To reply to your query. It really is not possible to create a .Net application without the .Net frame work. And moreover if you have installed Visual Studio by default it would have asked you to install .Net framework or would have installed it by default. In that scenario there is already .Net framework installed in your PC.
Thanks