Working with Octopus Deploy, trying to deploy our SSRS reports packages. I used a community powershell script, which uses New-WebServiceProxy to create proxies for the report server web services so that it can upload reports etc.
Found that we have intermittent timeouts when calling New-WebServiceProxy. Sometimes it will come back immediately, sometimes will timeout 2 or 3 times in a row.
We checked all the usual things
making sure the site was running (not cold) when making the call etc.
different users with the right permissions
Creating a fresh SSRS isntance on a different server
No change.
As a final step in debugging, I created a console app in visual studio with the intention of adding the web service proxies there and replicating the functionaly of the powershell script (as a test).
Going to Add Service Reference --> Add Web Service Reference" in Visual Studio gives identical behaviour (after pasting in the URL and clicking the navigate/go button) as the New-WebServiceProxy call in powershell.
Sometimes this timed out or hung (requiring a VS restart). Sometimes it worked quickly.
Because of this, I'm wondering
Is there any known issue with these methods of creating web service proxies.
Has anyone else found intermittant timeouts when doing this? (I found mention of similar hangs / crahses in VS, but no answers).
Once the reference was added in Visual Studio, actual use of the proxy was quick and easy.
Is there a way to create a web service proxy in Powershell from a fixed definition (not from the URL) and still be able to change the target URL?
Is there a way to persist the proxy, or to use one generated in C#?
Any other suggestions gratefully received.
Update
Could this be user account related? If I run:
Invoke-WebRequest -URI https://ssrs-server.domain/ReportServer/reportservice2010.asmx?wsdl -UseDefaultCredential -UseBasicParsing -OutFile ReportService2010.wsdl
on my local machine, or on the deployment tenticle logged in as myself, it comes back near instantly. If I run it via Octopus deploy console, it takes randomly between 1 and 3 minutes to complete.
Any ideas on why this should take so long when running in that context?
Related
I've recently inherited a number of WCF webservices that are configured to use an ASHX handler within a web project to render the .SVC files in the form of http://example.com/Services/V1/MyService.svc. The services are running in the dev and production environments, WSDL comes up, and adding a service reference in a new project allows me to call MyMethod and get a response exactly as expected.
The error handling and logging story isn't great, so I'm trying to run the site locally and add a service reference to http://localhost:1234/Services/V1/MyService.svc. I can load the service at that URL and see the same WSDL that appears for the production environment, but when I try to use code similar to what's below to call my method neither the client nor the response objects are recognized the way they are when I connect to production.
using MyServiceTestProject.LOCAL_MyService;
//...
MyServiceClient test = new MyServiceClient();
MyServiceMethodResponse r = test.MyServiceMethod("arguments!");
I am able to see exactly one of the MyCustomObject classes that is only declared within my service and stops being available when I stop using the service reference, so I know that something is coming across even if it's not everything that one would expect.
The relevant parts of the Web.Config files are the same when I compare my local and dev/prod environments, and the project that's running locally is the one that was deployed to those other boxes.
Has anyone encountered this sort of behavior runnning a services project locally using IIS Express?
Edit:. The endpoints are different between the prod, dev, and local environments, using the same code in each one. Thanks for pointing out that detail I'd omitted originally.
After spending several hours on and off trying to solve this before posting the question, deleting and re-adding the service reference and restarting both my IDE and my computer to no avail, I've discovered that right-clicking on the name of the service and selecting "Update Service Reference" (circled in red in the screenshot below) would ultimately fix the problems I was seeing although VS sometimes required me to perform multiple updates before it would work.
Without performing the update, neither my attempts to delete and add the service back nor restarting Visual Studio/rebooting my PC would help address the issue. I'm not sure if it's something about IIS Express that causes the service reference to not be created with all of the necessary data the first time around or if it's one of a hundred other variables in my local environment, but at least there's a reliable way to get it working when it does fail.
Our web application is developed by 2 teams. One team works on the client side, with it's own Branch for development, and the other works on the server side, also with it's own development branch. The client and the server are running separately, each one as a website on a different port. The websites are hosted over IIS Express during development, and in production they will run over IIS.
Our ideal situation is that each team can develop completely separately and whenever a develop session is over, both teams merge their change-set to a common Branch in order to integrate, than each team merges back to their development branch, and continues.
In order for a full separation, We have x2 SERVER projects, one to handle the real HTTP requests and another one, a "Stub server" Which responses to all the clients HTTP requests with default values, just in order so that the Client side team can test their code without being dependent on the functionality of the server.
The problem is that both the "Stub server" and the real server and using the same Port which the Client side project is directed to.
This causes many annoying mistakes (mostly for the Server side team) of running the application with the "Stub server" instead of the real one, during reviews, tests etc. The only solution for us is to manually create a virtual directory for the real web server project every time before running / or after finding out we were running the wrong server.
Is there a smarter solution to overcome this annoying problem? That would improve our lives!
If anything I said was foolish / not clear please correct me (I'm new to this), or ask for more details, I'll be glad!
Thanks for helpers!
I believe your problem is more related to build automation then server configuration. You should really keep the stub server and the real server into separate ports, and change that port during some kind of build process of your client.
If you are using AngularJS, then I suggest you to create steps into the build process of your client application using common tools like gulp or grunt. You could create build processes that will set a global variable or modify a constant (e.g. the API endpoint) and name them local testing (pointing your client to the stub server) and integration (for the real server).
Please note that you can easily integrate those build processes into Visual Studio, making them part of your global debug/build process.
Here it is a simple gulp task useful for replacing text inside any file: https://www.npmjs.com/package/gulp-replace
I've been following this series of tutorials (https://msdn.microsoft.com/en-us/library/ms734712(v=vs.110).aspx) on getting started with WCF, and it's all been going well up until step 3 (https://msdn.microsoft.com/en-us/library/ms730935(v=vs.110).aspx), specifically up until the bottom, where it says "Open Internet Explorer and browse to the service's debug page at http://localhost:8000/GettingStarted/CalculatorService"
Basically, what this should be doing (I assume, I've never tried this before today) is opening some sort of web interface to this service, where I can edit it.
I've tried using both Chrome and IE, and neither of them can connect. I've tried lots of different IP addresses (localhost, 192.168.1.8, etc.) and they all give back the generic "This webpage is not available".
I'm using Visual Studio 2015 Preview (that MIGHT be the problem, but it shouldn't be...) run as administrator (I've tried running the .exe directly as well) on Windows 8.1, coding in C#. I'm not too experienced in networking things, so I might be missing something obvious... any ideas?
I found the problem. In the main library (the one with the contract and implementation), in App.config, I forgot to change the address that it binds to. Setting this to the desired one (http://localhost:8000/GettingStarted/CalculatorService) seems to work.
HTTP 400 is significant. It means bad request - eg your service isn't receiving input in a way it expected, but it is there. Please update your question. That sounds like a mistake in your WCF config. Try this... Open up a command prompt and run C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\VsDevCmd.bat (Path for 2013, update as req'd). Then enter the command wcftestclient. It'll open up a gui that you can connect to the same url you're browsing to. It will attempt to talk to any WCF service listening there.
I am attempting to publish an Azure cloud service. Approximately 1 hour after beginning publishing, it returns this error. I am publishing through Visual Studio 2013 ultimate.
I am attempting to create a test Orleans-based service (not one of the samples). I have gone through the step-by-step cloud deployment tutorial and can't find anything that I might have missed. I would bet there is something in here though, like setting some connection strings wrong somewhere. I will be going through it again to make sure everything is as it is in the tutorial (unless there is an error there).
Also, I am using a mobile service as the API front end. There could be something in setting this up that's causing issue as well, as it differs from the samples I've looked at.
I think this usually happens when you create a new publish profile or in a slow internet.
Things you can try.
Restart Visual Studio
Sign Out and Sign in Again for your Azure Subscription.
Minimize your deployment Package Size
Disclaimer : I have not tried the 3rd point myself yet. Test in staging environment or UAT environment before trying this on production to avoid trouble.
Here's few things you can try:
Make sure the time stamp match on client and server.
Republish using publish setting you download from Microsoft Azure portal site.
When using Mobile Service, make sure you have 'X-ZUMO-APPLICATION: ' in your HTTP header.
Something you can try also is to check the size of all files uploaded and compare them with a "local" deploy. Maybe one or more files could be truncated.
In my case I think it was a slow upload speed that was causing that error when trying to publish directly from VS. I had then to do a Package and upload via the Azure portal and it worked fine.
I have created a web application in ASP.NET, with C#. I am getting the following message in my browser window when accessing the application:
---------------------------
Windows Internet Explorer
---------------------------
Stop running this script?
A script on this page is causing Internet Explorer to run slowly.
If it continues to run, your computer might become unresponsive.
I researched into the problem and found the following link, which is proposed as a solution to this problem:
http://support.microsoft.com/kb/175500
I want to execute this setup when a client accesses the web site for the first time. How can I run this setup on the client side?
It is not possible to fully automatically run some program from a website as #cHao said, this is what all browsers prevent.
But you may look at ClickOnce deployment, it allows for very fast and easy installation of your program literally in one click.
http://msdn.microsoft.com/en-us/library/t71a733d(v=vs.80).aspx