I have a third party assembly that I need to reference from a signed assembly that we build. I know how to do this, however, what kind of potential implications might I expect from signing their assembly ourselves?
Here is some additional information about the scenario:
The assembly is used to talk to a third party service which we do not build ourselves.
At this point, the unsigned assembly is only used to get information which is converted to a new format which has been developed in house, so we don't wish to pay support to the third party in order to obtained a signed assembly since we are phasing it out.
This third party assembly is merely an assembly for .NET applications to interface with the third party API which was not written in .NET (I think it was written in C/C++).
My main concern is that if I sign the assembly, it will not be able to interface with the service/have issues utilizing the native assemblies which are installed by the third party, though I have never had to do this before so I don't know if there is anything else I should be concerned about when signing third party assemblies. Any assistance in clearing this up is greatly appreciated!
In my case, it all ended up working when I signed our third-party assembly. However, there are some things when signing a third-party assembly you need to take into account:
Any native calls in the assembly will probably fail
Modifying third-party assemblies may be a violation of your software agreement
These are the only gotchas I've been told about so far (assuming you do properly sign the assembly in the first place).
Also as an FYI, In my case it would have been better to remove the unsigned DLL from the project reference and use Assembly.Load or Assembly.LoadFile to load the unsigned assembly from the signed one.
Related
Where is the best place to create a Services folder in a C# Blazor Web Assembly (ASP.NET Core hosted) application? A Web Assembly (ASP.NET Core hosted) application has 3 projects for 1. Client, 2. Server and 3. Shared.
My initial thought is to place the Services folder in the root of the Shared project. Is there a best practice of where the Services folder should be placed for this kind of application, maybe in the Server project for example?
I have created a Service to read a CSV file which I have registered with the Dependency Injection service to make it easier to access throughout the project and also for testing. I will be adding other services as well so would be good to know if anyone else has a preferred place to add those services normally?
Thanks for your time.
It's important to understand what is sent to the browser and what is kept on the server-side. The Client project has reference to the Shared project (by default), so once compiled both projects Client and Shared will be sent to the browser (as .dll). The Shared project is also referenced by the Server project, and it acts like a "bridge", holds some common constructs. Having that said, I'd suggest you do the following:
Client project - You place all your client-side logic, your razor components, your views, and the code that calls various API endpoints (or it might be gRPC calls).
Server project - Here you keep all your API endpoints and back-end services.
Shared project - Since this is referenced by both, a copy is sent to browser, and another one kept as part of your server application. This is a good place to put all your Dto models. Avoid placing any services or any logic-related constructs. The common constructs between Client and Server are the models only. Having a shared project is just a convenience, you can of course opt it out completely, and duplicate your models in both places.
I have WCF web application project and I've added three classes to the App_Code folder. Now I want to register one of these classes (which inherits from BehaviorExtensionElement) as an Extension Configuration Element.
I'm in the WCF Configuration Editor and I'm at this screen:
When I browse for the Type, I'm forced to choose from a set of DLLs. But my Behavior Extension Element isn't in a DLL. It's in app_code.
So how do I choose it? Do I have to put it in a separate library?
UPDATE:
You can definitely do it within a WCF Class Library, which is where I was doing my testing for this particular feature. Then I implemented it in a WCF Web application and it didn't work. Alright. Well, I just created a library and included it and everything is working now. Still would like to know if anybody can get it working without a separate DLL.
I have a 3rd party web service, which I intend to use from 2 different applications:
a Windows Workflow (WF) project
a website
Right now, from these 2 apps I manually add the reference to the 3rd party web service & call the required method. This means I have this proxy layer generated in 2 places.
What am looking for is a way to create (am not sure about the correct word to use, sorry guys) the 3rd party web service in one place & have the 2 applications re-use it.
Can this be achieved using WCF, something like wrapping the 3rd party web service in WCF.
Is this approach right?any help or pointers would be a great help, haven't done much service based development.
Environment: The website, the WF project resides on 2 different servers (windows 2003 R2).
Environment(development): windows 7 enterprise/vs 2010 / c#
Thanks
More detail:
Think I dint use the right words in my first query, the following is what am looking for & why I need it that way,I need to call the 3rd party web service from a new WCF service.This new WCF service will be called from other applications(winforms/WF/website) instead of calling the 3rd party service.The idea is to able to switch the 3rd party service(vendore) without changing the implementation & in one place.We use an hr-xml format for request/response & all our vendors(exisiting or future) support the hr-xml format for the industry we are in.If we use a class library, then to change vendor, we should recompile & distribute the dll correct,we dont want to do that. I am not sure about an architecture to be followed to achieve this whole functionaity.Any pointers in the right direction would be a great help.
Thanks
Your quest makes great sense indeed - and I think it should be quite easy to accomplish:
create a new class library assembly ("WebServiceClient" or whatever you want to call it)
inside that new project, do you Add Service Reference - this will create the necessary WCF proxy classes and the config file
compile that class library
From both your apps, you should be able to reference that web service client assembly, and use it - you have the code for the client side proxy only inside that common assembly, but you can use it from any number of apps.
One point to remember: you will need to copy&paste the config for the web service to the main application's config (app.config for a Winforms/console app, web.config for a website/web app) since it cannot be read directly from a class library's config file (that won't be used by .NET).
In this case, I think, WCF service will be the gr8 idea. You dont want to recombile the client applications if the vendor is changed.
I have a Client website, a WCF service and a library of domain objects (.cproj).
I want the client to use my library of domain objects directly, not the proxy generated version of the domain objects. Is there a simple way of doing this?
Include a reference to the dll in your client project. Then add a Service Reference. When you add the service reference there is an option to use the types in the dll and not create them in the references.cs.
Include the library project or DLL in your client project rather than creating a service reference. You can generate the service reference to create all the necessary WCF configurations to call the service, but just don't use the generated proxy or datatypes (e.g. the code in Reference.cs) - use the types in the included DLL directly. You may need to write a client yourself, but this is simple, and can be basically copied from the generated client in a service reference.
That said, sharing the datatypes directly between the client and service sort of breaks service-oriented architecture patterns. Now both your client and service are dependent on the same DLL, rather than the client just being dependent on a service.
a question concerning the new concept of Trusted Applications in Silverlight 4:
I gather that trusted applications run outside the browser with elevated trust. Will it therefore be possible to call arbitrary functions in unmanaged DLLs (by means of DllImport) from a trusted application or is this feature still reserved to proper desktop applications?
Thank you very much in advance and kind regards,
Marc Frei
Unfortunately, Silverlight 4 does not allow calling unmanaged code via P/Invoke. You can only call native code using the COM via the AutomationFactory class. However, calling native code was added to Silverlight 5.