I have a project that uses web references to make SOAP calls to several web services.
When I'm working locally, the services are hosted on my local machine, so the URL of each web service is something like http://localhost/blah.
When I deploy the project to a server, the URL needs to change to the production URL.
Currently I am accomplishing this with a prebuild event that does a find-and-replace on each URL and overwrites it with the deployment URL before deploying. Surely there is a better way.
Can someone enlighten me on the best way to change web references for deployment?
This happens to be a VB.NET project in Visual Studio 2010.
If you set the URL behavior of the Web reference to dynamic, the application obtains the URL at run time from the appSettings element of your application's configuration file.
So, you can use code to set it based on where it is deployed. This is a pretty old link, but I think it should help:
http://www.codeproject.com/KB/XML/wsdldynamicurl.aspx
Related
I am trying to get my code to run alongside, in process, with an asp core web site.
With .net framework there is an option to create a module. Then, in order to "inject" that module so that it is run when the site runs all I need to do is add the module to web.config or launch it from a .cs file from \app_code.
With asp core, there is a concept called middleware but in order to add a middleware, the user has to write it into their startup code.
I need a way to run my .net core code when the site has started (first page accessed) without requiring the user to change their code to do so. Changing config files after deploy is OK but not compiled files.
Anyone know how to do this?
Thanks.
I see 2 options here:
Hosting startup assemblies
An IHostingStartup (hosting startup) implementation adds enhancements
to an app at startup from an external assembly. For example, an
external library can use a hosting startup implementation to provide
additional configuration providers or services to an app.
IIS modules with ASP.NET Core - you may still be able to inject your module in case you run the app on IIS. Add a web.config manually into the root directory and configure your module in there.
Good Day Everyone -
I'm using VB.NET within VS2013 (Professional) and have a question about defining a Web Service binding via code.
I can successfully had a Service Reference via Solution Explorer and connect to a specified URL for the web service I'm trying to access.
What I am looking for is some direction on how to define the endpoint via code; the web service I'm hitting will be local to each facility and I need to allow a user to define the endpoint URL on the fly.
Any thoughts or insight would be appreciated.
After researching I found the problem.
When I connected to the Web Service VS stored the connection details in app.config in the folder of the project. At run time, VS compiled the app.config into .config which had to go with compiled application.
Once I did this I was able to connect without a problem to the defined WS outside of VS. Once basic connection details were present, I could successfully override the remote endpoint with whatever the user inputted.
I have an ASP.NET MVC/WebAPI mixed project which runs just fine in the VS2012 development server. It has a standard MVC {controller}/{action}/{id} route, as well as an additional WebAPI route api/{controller}/{id}. Requests which start with /api/... are directed to WebAPI, the others to normal MVC.
When I deploy it to the local IIS, the normal MVC routes are working. However, /api calls to WebAPI are resulting in the exception
Access to the path 'C:\inetpub\wwwroot\myapp\web.config' is denied.
Then I tried to set the proper security permissions on the inetpub folder and its subfolders. This didn't help anything, and because the normal MVC requests are working, I don't suspect the problem to be security-related.
Then I started Sysinternals Process Monitor to see what w3wp.exe is doing during the request. As it turns out, IIS looks for web.config here:
C:\inetpub\wwwroot\myapp\api\web.config
C:\inetpub\wwwroot\myapp\api\mycontroller\web.config
Of course, there is no web.config there.
How can I set up IIS to recognize both routes?
I do not believe this is a problem with your routing. the problem is the permissions given to IIS I run into this error from time to time. Depending on the app pool identity you are running under you need to provide permissions to that entity. Here is a link to a very thorough explanation
IIS AppPoolIdentity and file system write access permissions
Basically right click your project folder, go to properties, click the security tab and and you will see Group or user names. These are the allowed entities to perform read and/or write actions to that directory. Click Edit then Add; from here you will then "Enter the object names to select" typically IIS follows under IIS_IUSRS again this depends on your app pool configuration from here you should move on from the error mentioned!
I hope this helps!
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 am working on a Silverlight application that uses WCF. I need to have my WCF project separate from the ASP.Net application that will host my Silverlight project. I am looking for some guidance on how I should organize my solution and list gotchas other people have experienced during debugging and deployment.
Specifically my questions are
What type of project should I use for the WCF service?(A WCF project, an ASP.NET project with self-hosted WCF services, something else)
What do I need to so to get it so that when I press F5 I can debug both my Silverlight project and my WCF service? Will I need a cross-domain policy just to debug the thing?
Some background info on why I want to do this:
I have legacy web application that I am gradually converting over to a Silverlight application. Because it is a large web application some of its features will be converted to Silverlight before others.
The legacy web application has lots of code in it that is no longer used. Much of the code that is no longer used references 3rd part assemblies. This is why I want to get rid of the old web application. So obviously I don't want to host WCF services that will be kept for future versions in it. That is my reason for wanting to make the WCF project separate.
We're doing the exact same thing.
We're using a WCF project just in case we have to change how it's hosted in the future. (I.E. no longer using IIS)
2.a. You can have a solution with your silverlight projects, and your wcf project. The silverlight project will have a service reference to the wcf service in your solution. That allows you to debug using F5. However, when you go to deploy, you will have to change your app.config service URIs to refer to your production location.
2.b. You will only need a cross-domain policy file if your fully qualified domain names are different for the wcf service and the silverlight app. Ours happen to be different. Here is an excellent article on when to use the policy file: Clicky
Good luck!
Just remember that when you get ready to deploy, if your service is going to be hosted on a different machine than your app, you need to deploy the service first. Then re-configure your service reference, and finally re-compile your Silverlight before deploying. Otherwise, your Silverlight app will look for the service on your local machine instead of where you deploy it.