My problem is the opposite of many problems...
We have a WCF web service which works fine on our 'live' IIS server.
When I run the code in VS (even if running as admin) on the dev machine, I get nothing in the browser, and cannot request ?wsdl which also works on the server.
The web config files on both machines are identical.
What is wrong here, please?
EDIT:
I have added a new WCF project to the solution. That one DOES show the service, present the WSDL and allow browsing of the folder contents.
I copied the web config setting:
<directoryBrowse enabled="true"/>
into my existing web config, but it still won't allow directory browsing.
Related
-My Web API project running in its own project is fine.
-Trying to run my Web API project from within a solution which contains another web project I get the following suggestion given its 'forbidden'
1. Go to the IIS Express install directory.
2. Run appcmd set config /section:system.webServer/directoryBrowse /enabled:true to enable directory browsing at the server level.
3. Run appcmd set config ["SITE_NAME"] /section:system.webServer/directoryBrowse /enabled:true to enable directory browsing at the site level.
The first appcmd suggestion works fine, the second does not. I believe the reason is because my site name does not exist in iis Express until it runs or I am doing something else wrong.
This leads to the last question.
-Can I even have a Web API project running while another web project in the same solution consumes its methods. I assume the answer is no.
In fact I assume that if I want to have a web application consume the methods of this Web API application I am going to have to install a proper IIS stand alone.
I have three mvc 3 web applications in a single web role on Azure Cloud Services. All of a sudden this morning both the single instance in production and in staging give "HTTP Error 503. The service is unavailable." when navigated to in a browser.
I rebooted the production instance but nothing changed. Then I deployed a remote desktop enabled version to the staging instance and logged in. However, strangely when I navigate to the web applications in a browser inside the remoted staging instance everything works.
Looking at IIS server logs it seems there are some issues starting the roles (warning level about the appPoolId being incorrect) but obviously the roles are starting as they are accessible from inside the staging server.
The World Wide Web Publishing service is also running and even after restarting this service the web application is not accessible externally.
Does anyone have an explaination for why the sites are accessible locally but not remotely that would help me debug this issue?
I found out where the issue came from, the bindings that were configured in IIS7 did not include bindings for the actual [abc].cloudapp.net host headers.
I assume that for some reason since some time last night or this weekend the requests seem to come with those headers instead of the original headers for the website. This is really strange but adding these bindings fixed both the staging and production instances and they were available again after this change.
I've created a Silverlight application that uses a service. The service is defined in the web project in that solution. The silverlight application references it and uses it.
Everything works locally on my dev machine when I run the application in Visual Studio.
I note that the url im given from VS is: http://localhost:50453/Default.htm
But when I deploy this (by filesystem copy deploy option) the web page starts and it looks okey except that it seems to have a problem using the service.
In the Silverlight application, if I look at the reference settings the url to the service is: http://localhost:50453/SilverlightService.svc and thats probably whats wrong, as the server that Im deploying to does not have a clue whats on port 50453.
So Im trying to change this port to 80 on my dev machine but Im out of luck. My web project does not have any property where I can change the port. Opened URL and URL is locked at http://localhost:50453 :-/
How can I change the my dev environment to match the production environment with port 80?
For sure you can change the web project's URL in project properties, but this is not a good solution because you'll get the same problems when accessing the SL application from a remote computer.
You need to set the service URL programmatically, like above:
ServiceReference1.Service1Client svc = new ServiceReference1.Service1Client();
Uri serviceUri = new Uri(System.Windows.Browser.HtmlPage.Document.DocumentUri, "Service1.svc");
svc.Endpoint.Address = new System.ServiceModel.EndpointAddress(serviceUri);
This solution uses the same URL that you are using to access the Silverlight Application.
I have a WebApi project that wraps the Dynamics CRM Online web service and provides a REST api. I have a simple controller that gets some contacts from CRM and returns them to the caller.
Everything works fine when I run it in the local emulator. However, when I deploy the project to Azure, I can reach the home page, but the controllers all return http 500 errors. Why would this happen? And how can I troubleshoot to get more details?
UPDATE
The issue is with the absence of Microsoft.IdentityModel.dll on the Server 2012 instance running the web role in Azure. I found this by opening web role instance in RDP, installing Fiddler, and making the request from Fiddler to the local IIS server. It responded with the detailed error.
Now my issue is figuring out how to enable IdentityModel on a Windows Azure Web Role. You're supposed to be able to add it via the Server 2012 Add Roles and Features wizard, but it's totally locked down on the Web Role. You can't check any boxes that aren't already checked. Is this even possible?
The issue is giving the Web Role access to Windows Identity Foundation when it's inherently not there. Marc Schweigert provides clear steps to do this here:
http://blogs.msdn.com/b/devkeydet/archive/2013/01/27/crm-online-amp-windows-azure-configuring-single-sign-on-sso.aspx
Go to the 23:00 mark of the video and you'll see the 4 necessary steps:
Reference Microsoft.IdentityModel.dll (need WIF SDK installed)
a. Set copy local = true
Create RegisterWIFGAC.cmd in your web role project
Create Startup Task in ServiceDefinition.csdef that invokes RegisterWIFGAC.cmd
Add GacUtil to the project (used in the startup task) to put Microsoft.IdentityModel.dll in the GAC every time the web role starts).
I'd developed a WCF Service using netTCPBinding and embedded it in a Windows Service.
The configuration data of wcf is located in standart app.config file.
After that i had created an installation project and include my code (wcf in widows service) there. So I have the setup.exe file to install my windows service with wcf on board.
I've installed the windows service to my local drive (C:\Programs Files...\Service) and started it using the services page (pane) of my OS.
It works fine.
The app.config file was copied to the local drive and located across the same folder (C:\Programs Files...\Service).
One day i've tried to change the part of my endpoint address (PORT) in app.config (C:\Program Files...\app.config) and restarted the service using an appropriate page of services (services.msc) in windows.
I thought that the service would be working on another port (I've setted in app.config) but i was wrong. The service continued working on the previous PORT. As I've understood, it continued working using the copy of starting version of app.config. It stores the copy of this file in another path.
I need the ability to change the app.config file and get the updated windows service after it's restarting.
I am going to let my users set the specified port number where the developed wcf service will listening to.
Where am I wrong? Could you help me to find the solution of my problem?
Thank you for your help.
At the risk of stating the obvious...
How literally do you mean that you changed a file called app.config? Do you mean that you changed the file called [exename].exe.config? 'Coz if you changed a file called "app.config" in the installed-to folder, that file won't have any effect. You need to make the change in the file called [exename].exe.config.
--Shawn.