Our desktop app talks to a piece of software on a remote PC (which in turn controls an industrial device). Our app references a "client assembly" that was provided by the manufacturer, and is essentially an API exposing numerous methods, using WCF under the covers (over TCP). The target framework of this 3rd-party client assembly is .Net 4.5.
I'm in the process of migrating our desktop app to .Net6, and initially encountered the following exception on startup:
System.IO.FileNotFoundException: Could not load file or assembly 'System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. The system cannot find the file specified.
This was fixed by adding the "System.ServiceModel.Primitives" NuGet package. (I had a similar exception for "System.ServiceModel.NetTcp", again fixed by adding that package).
I've run the portability analyzer (ApiPort) on the 3rd-party assembly, and every one of the messages relates to System.ServiceModel, e.g.:
"DefinedInAssemblyIdentity": "System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089",
"MemberDocId": "T:System.ServiceModel.MessageSecurityOverTcp",
"TypeDocId": null,
"RecommendedChanges": "This part of Windows Communication Foundation (WCF) won't be ported to .NET Core. See https://aka.ms/unsupported-netfx-api.",
"SourceCompatibleChange": "",
"TargetStatus": [
null
]
With this in mind, and having added the earlier NuGet packages, how confident can I be that this assembly will work happily in our .Net 6 app? (It's going to be a while before I can actually test this area of the migrated app for real).
.NET 6 support for WCF is less comprehensive, despite Microsoft's efforts. The mainstream option is CoreWCF. There are still some issues, but some common features of WCF are supported.
There are other options, such as gRPC, which has the advantage of being flexible and can be used across platforms and frameworks.
Related
I need to upgrade an existing windows 8.1 Mobile app to work on windows 10 and started looking into this.
I have managed to port the code to UWP and it builds and runs the UWP app - so far so good.
However within the app there is a WCF project which is used to go get data and this isn't working.
I am currently getting this error Could not load file or assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Is it even possible for a UWP app to contain a WCF project and this will work?
In the VS2015 solution this all works but in VS2019 it doesn't work as in the ServiceFactory class cant even create an instance.
I have next to no experience of UWP or Windows 8.1 Mobile apps and any advice would be great.
Thanks
Gregor
Note that the WCF Client is actually available for .NET Core/.NET Standard! It's only the server-side part that is not available for .NET Core.
WCF Service: .NET Framework
WCF Client: .NET Standard based (works with .NET Core and .NET Framework)
In your case, if I understand you correctly, you want to call an existing service, which means you need the WCF client, and you can actually use that WCF client with .NET Core/.NET Standard 2.0 and so also with UWP.
Do the following:
Add a new .NET Standard Class Library project to your solution (this will replace the WCF client library that you have already in your solution)
In Solution Explorer, right click on Dependencies and select "Add Connected Service"
This will bring up a page within Visual Studio where you see the "Microsoft WCF Web Service Reference Provider":
Click on it, and the dialog below opens up:
In the dialog above, type in the URL of your service, and the dialog will generate the whole WCF client code for you and it will also add references for the required WCF NuGet packages.
Reference the .NET Standard 2.0 class library project from your UWP project and use it.
Note: WCF-Client in .NET Core does not support the configuration file entries known from .NET Framework projects. That means that the configuration is generated in the C# code.
I hope this helps,
Thomas
I want to generate word documents from my ASP.net MVC 6 website. I've implemented several ways to generate a document in a POC : DocX, NetOffice, OpenXml, COM Interop objects. I was seduced by it.
I made a Console App to test and it works.
But, with ASP.net MVC6, we can't reference Console App's or COM Assemblies.
We need to create "Console App (Package)".
How can I add COM Assemblies to my ASP.net MVC 6 website ?
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
You can read more about that in the Considerations for server-side Automation of Office article.
Consider using third-party components designed for the server-side execution or if you deal with open XML documents you may use the Open XML SDK, see Welcome to the Open XML SDK 2.5 for Office for more information.
My website application uses C# COM+ components running under a particular identity to access SQL Server, invoked from classic ASP.
There's also a web service that utilises a \bin DLL in the website application that contains a method to insert some data into the SQL Server database (let's call it MyApp.Database.dll).
From the website front end, I want to be able to provide authenticated users with this same functionality.
I don't want to duplicate code in MyApp.Database.dll within the COM+ component for obvious reasons.
My idea was to utilise the COM+ component from ASP to invoke the MyApp.Database.dll method to access the SQL database using the application credential since the ASP is running as the user and has no access to SQL Server.
Problem I've seem to run into is that although I can reference MyApp.Database.dll in my COM+ component project (under 'References' and 'using MyApp.Database.dll'), when it comes to actually running or debugging the COM+ component, when it tries to invoke the method from MyApp.Database.dll, it tells me 'Could not load files or assembly 'MyApp.Database, Version=3.3.3.11658, Culture=neutral, PublicKeyToken=.....' or one of its dependencies.'
The MyApp.Database.dll is not registered in GAC (trying to avoid this, it's also used by other applications as well), and hasn't had its codebase registered in the registry using regasm (I tried this and still didn't work). The version is correct, and I've placed MyApp.Database.dll in the application folder of the COM+ component.
Am I missing something or is it not possible to do this?
Thanks in advance for your help.
This is a common mistaken expectation: just because your .NET COM DLL was found in some given folder (the folder set by the /codebase argument or RegAsm) -- it doesn't mean .NET will look on that folder for anything else.
Generally speaking, it won't. Loading a .NET assemblies via COM interop is a special case. For everything else, assemblies will be loaded in the AppDomain based on the Fusion binding policy for the process - which has nothing to do with where your .NET COM DLL is. The process is actually (depending on your version of IIS) either dllhost.exe, iisexpress.exe or w3wp.exe.
You have a few options.
First, the obvious solution is putting MyApp.Database.dll in the GAC, since .NET always looks there. Sometimes that's the right choice (I've done that and it works). You have declined to do so and you have your reasons; that's Ok.
Second, I believe you can change the binding policy with a web.config file. See here: http://msdn.microsoft.com/en-us/library/823z9h8w(v=vs.110).aspx. Yes, your ASP Classic project can have a web.config. Obviously it has no effect on your ASP Classic scripts, but (depending on the version of IIS), .NET and/or IIS itself use it for configuration. I'm afraid that I can't help you much with this alternative because I've never had to try it before, but you're welcome to explore that option - let me know how it goes.
Third option - my personal choice: You said this DLL is already a web service, right? Just call the functionality with a web service call from your COM DLL. That doesn't require mucking with magic folders, GAC and binding policies. Much cleaner. The only mild complication is tracking in configuration where your web service is located - and I bet you already do that for your database connection anyway, so it shouldn't be hard to add.
If you are curious to know where .NET is looking for the DLL, read up on these guys:
How to enable assembly bind failure logging (Fusion) in .NET
http://www.hanselman.com/blog/BackToBasicsUsingFusionLogViewerToDebugObscureLoaderErrors.aspx
http://www.hanselman.com/blog/MoreOnAssemblyBindingStrongNamingTheGACPublisherPolicyAndDynamicallyLoadedAssemblies.aspx
Good luck, and please let us know what worked for you.
Can VS2012 build a proxy in a PCL project to consume a WCF service for SP2010? We add a reference (old school works everywhere else) but once we make calls, for instance GetListsCollectionAsync(), we get all sorts of errors. When we build the proxy, VS gives a warning:
Service proxy generation failed. Proxy requires type 'System.Xml.Linq.XElement' which is not supported in portable libraries
Has anyone successfully subscribed to a SharePoint WCF using a portable class library? The same stuff works fine in .net 4.5 class libraries and in metro libraries. Only portable ones give us this problem. We have win 7 and win 8 devices in the mix - so PCL would be a really good fit.
Got a conclusion here: We found a work around and the statement that this is a bug in VS2012 PCL projects still stands.
We created our proxy in a metro project and simply copied the reference.cs file over into the PCL project. It was a "what the heck - why not" last attempt of sorts, but it actually works. Even better, the calls are awaitable and come with response objects. Awesome!
Cheers,
Gregor
there! I have a library written with .Net Framework 4. This library exposes some objects as COM via System.Runtime.InteropServices, which are registered with the regasm utility. These objects are intended to be used by an old (not .Net) ASP page, which is configured under an application that runs .Net Framework 2 (I know!!!) on IIS6 (Windows Server 2003).
Everything seems to work, except for the configuration file. When the .Net 4 COM object attempts to access System.Configuration.ConfigurationManager looking for a connection string, it gets a Null Reference exception. The web site has a Web.config file, and obviously the connection string is there, but the library can't find it. I think that it's because the Web.config is for the .Net applications running under IIS, and the COM library is seen as an external component.
I don't know where else the library might be looking for a configuration file. Changing the machine.config in the FW4 folder works, but I'd like to know if there is another location I could use, because machine.config is system wide and I don't want to pollute that, especially with connection strings. I tried adding a mylibrary.dll.config file in the DLL folder, but it doesn't work either.
Thanks in advance