I have the need to create two web services. They do the same thing, but one has web references to "testing" services. The other has reference to "live" services.
I'd like to create and maintain one set of source (.asmx) files using c# in Visual Studio 2010.
I've managed to create a solution which contains two web service projects. I even managed to reference (using Add Link) the same set of source files in each project.
However, when I go to call the asmx file, the web service, the file's not found and I cannot figure a way to distinguish which service I am calling; the asmx files only exist in the common folder area, not actually within each project.
If the testing and the live services use the same WSDL, then you do not need separate web references. Use a single reference, then set the Url property of the proxy class to point to the correct service.
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.
In my VS solution, I created a console project, which I'm using as the client, and an empty project for the WCF service.
I then created the WCF service (created my contract and service type and manually constructed the app.config), and added a reference to the WCF service project in the client project.
However, when I called ServiceHost.Open() in the client, the endpoints weren't loading. I eventually determined that I needed to put all of the config information in the Client's app.config, rather than the service's app.config.
I'm not sure if this is normal, or if I'm doing something wrong. In the past, when I've used the WCF project template, this wasn't the case.
Yes, that is normal. Each .NET application (client, service, web site, etc.) has it's own configuration file. To be precise, there's a hierarchy of them, but the bottom end of that hierarchy is unique to the application.
This makes sense if you think about it -- the client would need to contact the service to ask for it's configuration, but it needs to know the endpoint information in order to even try to do that. So yes, the normal process is that client and service both have very similar information in their configuration files.
If you use Visual Studio's built-in tooling to do everything for you, it will automatically create and/or edit the configuration file for your client when you add a Service Reference to the project, copying from the metadata endpoint that WCF exposes for that purpose. Alternatively, you can use the WCF configuration editor tools to edit your client application.
Also, note that nothing actually enforces that your client and server have compatible settings; e.g. you can change the maximum sizes of many buffers/graphs/etc on one side, and not the other, and see some strange behavior. It's up to you to make sure both ends are working with mutually usable settings.
Base:
I have created a ASP.NET web part to be deployed to a Sharepoint 2010 site. This web part is using a external web service, a WCF service that is hosted else where, not on the same machine as the Sharepoint site. The web parts are installed on the sharepoint server using a CAB-file that is created via a deploy project.
Issue:
My issue is that I have web service binding configurations in the web.config of my ASP.NET web part solution that I need to modify based on what customer is using it, so I need to be able to modify my binding address after installation (or during).
Other:
I have seen solutions using the SPWebConfigModification, but I have no local installation of Sharepoint so that is not an option. I have also seen pure C# solution where the endpoint address is hard coded in the assembly, but this will prevent me from modifying the address after compilation of the web part. The best way would be to have an external txt/xml-file that I can use from my web part to get the endpoint address from, or a smart way of updating the sharepoint web.config not using SPWebConfigModification.
so...
any one have a awesome solution to my issue?
Can you use custom webpart properties that will contain the WCF endpoint information? This way you will be able to configure your webpart(s) after they are added to a page. The properties are reachable from the webpart code so you can generate the wcf proxy in the runtime with no custom config files in the solution.
this article might help you with the custom properties http://www.lamber.info/post/2010/05/21/How-do-I-create-custom-properties-in-Visual-Web-Parts.aspx
Editing web.config is almost always the wrong place to put something like this.
Maks answer is good and certainly the easiest option, if you want to store the address of the web service in one place to be used by multiple web part instances then this option may be better.
SO - What is a proper way to store site-level global variables in a SharePoint site?
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.