I am working on getting web deploy set up on IIS 7.5. I have followed the steps exactly in this article:
http://www.iis.net/learn/publish/using-web-deploy/configure-the-web-deployment-handler
I have tested importing and exporting applications on the server and all work perfectly. Now I would like to set up remote access to ms deploy so I can install web applications by publishing in visual studio 2012 with publish profiles.
Here is where I am confused, what is the url I include in this for the service url (ie. msdeploy.axd)? Where I can find it on the servers iis (server is located on different machine than visual studio)? I have read about access is over port 8172, how can I check that this is open for communication?
Thanks for any help
First up, the installation instructions you want are Installing and Configuring Web Deploy in the "Install" section of the site. The instructions you linked are from 2008.
Once you've installed MSDeploy v3 as per the newer instructions, the MSDeployServiceURL value will be https://webserver:8172/msdeploy.axd. You'll also probably need to set <AllowUntrustedCertificate>true</AllowUntrustedCertificate> if you don't have a cert on the server.
The user in question will need to be an administrator unless you have setup non-administrator deployments (instructions in the same link).
Related
How can I configure Web Deploy on Windows 10? Should it work?
I found information about Web Deploy on Windows 8, there it isn't working.
How is it in Windows 10?
Microsoft is being super sneaky about this, but it appears they have removed the ability to use web deploy remotely from ALL non server os's. Even in Windows 7, if you do all of the newest updates, the deploy menu vanishes in IIS. So if you want to use web deploy it seems like your only option is to shell out some bucks for a server os.
HOWEVER, I was able to get FTP publishing configured and working on my Windows 10 machine, which works almost as well. Just install the FTP server under control panel => programs and settings => install windows components. Then open iis mgr and right click on your site and a configure FTP publishing option should pop up. The configuration is a pain and not straightforward, but if you mess with it you'll figure it out.
Then in Visual Studio right click on your project, hit publish, then in the first screen in the drop down there is the good old fashioned ftp option. Good luck!
EDIT
From OP's response, another solution is to simply share the root folder on the server, so for example
C:/inetpub/www
Then mount that share on your development box, I mounted it as the P:\ drive for production, and Q:\ drive for qa. Then in visual studio on the publish screen just select deploy to file system and deploy to that mapped drive, works like a charm and is far simpler than setting up FTP.
Ok, I did this (in Windows 10):
Uninstalled Web Deploy 3.6 from control panel(didn't help).
Downloaded Web Deploy 3.6 installer, then ran uninstall from the installation menu.
Downloaded Microsoft Web Platform Installer 5.0.
From the Web Platform Installer 5.0, I installed Web Deploy 3.5 + Web Deploy 3.5 without bundled SQL Support
I seem to have the deploy context menu back when I right click a site.
Make sure you do the following:
Install web Deploy 3.6
Go to Server Manager > IIS
Under Server Roles go down to Web Server (IIS), expand this tree and select Management Tools.
Make sure "Management Service" is checked
Go to Services, Make sure "Web Management Services" is started. (go ahead and make it automatic while you're in there).
Now you'll see the "Configure Web Deploy Publishing" option under the Deploy menu on IIS. From there make sure you have port 8172 open from the IP you are publishing from.
Installing WebDeploy 2.1 (available from the Web Platform Installer) gives you a 'Deploy' option on your website in Windows 10
See: https://serverfault.com/questions/253292/why-dont-i-have-deploy-actions-available-in-iis-7-manager
I have a multi site Azure based web application. One site contains the web pages (with the view functionality driven through jQuery, Raphaël, and HTML) and a thin WCF service. The second site contains a more functional WCF service which in turn calls the data objects that call the database. We stopped development on the site a few years ago but it is still live for the few people who still enjoy using it.
Yesterday I had to fix an cross-site scripting vulnerability someone had reported on the site.
I was alarmed to find that I can no longer run the sites on my local machine under Visual Studio to test and debug any changes before deploying them to Azure.
Because of the interaction between the two WCF sites I had the local debugging set up as follows:
In the Internet Information Services Manager tool (InetMgr) I add additional websites with their physical path set to the location of the source code in the TFS local path on my machine.
I edit the host name in the site's binding to mimic the Azure location, i.e. the main site is projname.cloudapp.net:80 on Azure and projnamelocal.cloudapp.net:80 in my local IIS and the data WCF site is projname-wcf.cloudapp.net:8080 on Azure and projname-wcflocal.cloudapp.net:8080 in my local IIS. (N.B. The main site has a HTTPS binding too.)
I edit C:\Windows\System32\drivers\etc\hosts to include the lines
127.0.0.1 projnamelocal.cloudapp.net
127.0.0.1 projname-wcflocal.cloudapp.net
In Visual Studio I edit the web properties for the main site's project so that it uses the local IIS and project URL http://projname.cloudapp.net/ and I have a switch (in the code to say whether to call the local WCF or the live Azure one.
In the past when the project was under active development this set-up worked fine for locally testing and debugging. Yesterday it failed, one one machine http://projnamelocal.cloudapp.net/ gave a 503 error on another a 404. (N.B. I can ping each URL from the command line so the hosts redirect is working.) Visual Studio complains that it is "unable to start debugging on the web server" and that it "could not start ASP.NET debugging".
I've tried all the suggestions and some:
Running without debugging
Running Visual Studio as administrator (I was already)
Re-registering ASP
Changing the app pool
Giving everyone full permissions to the code directory
Running as my own domain account that is an admin on the local machine
Changing IE to not auto-detect proxies
Adding the sites to IE's list of trusted sites
Turning off IE's protected mode
Restarting Visual Studio
Restarting the PC
Restarting the PC again
How should I set-up this style of running, testing, and debugging local sites work in IIS under Visual Studio?
Got it.
I had forgotten to go to Control Panel > Programs > Turn Windows features on or off > .Net Framework 4.5 Advanced Services > WCF Services > HTTP Activation
Now that I have that installed the local sites start
I'm using visual studio 2012 and i have a windows form app. the iis express server is configured by default with visual studio 2012.
I have to publish my windows form app. For that, i have create a storege object on azure platform.
But when i try to publish the project using clickonce i have that issue :
Error 83 The Web server does not appear to have FrontPage Server Extensions installed. If FrontPage Server Extensions are installed, this error can occur because the _vti_bin virtual directory is not marked as executable. To correct this problem, run Internet Information Services Manager, select the Web server that has the problem, and then use the Check Server Extensions command.
Screen shot :
https://docs.google.com/file/d/0B-aV0dsLT4CaemZuQV93Ymt4UVE/edit?usp=sharing
I had no issue during the creation of my storage object on azure, and the URL is good !
I have installed de FrontPage Server Extension several times and normally it's good.
i really need to publish my project, if someone can help me ...
Thanks for help.
You are trying to do HTTP publish to a server that doesn't have FPSE installed. FPSE was no longer available after Server 2008 (I'm guessing here, I just know it's not available for newer versions of Windows Server).
Instead of doing HTTP, use FTP. So you FTP the files to the web server, and use an HTTP link for the customer to access them.
For example, your publishing file location might be
ftp://myserver.com/myfolder/
and your installation URL would be something like
http://myserver/thefolder/
I have a web application asp.net to deploy to Windows Azure. I try to run it on local first. But when debugging, I catch this error from VS2010:
"There was an error attaching the debugger to the IIS worker process
for URL 'http://127.255.0.0:82/' for role instance
'deployment16(6).WindowsAzureProject2.WebApplication3_IN_0'.
Unable to start debugging on the web server ......."
I've search so hard to find the solution for this problem but there's nothing seems work for me. I'm a newbie in Windows Azure, it's really a big trouble with me.
I had similar problem with Windows 8, debuging a cloud application with Visual Studio 2012 RTM and Azure SDK 1.71, when trying to launch the application into the compute emulator. It was a very simple app, but I used Azure diagnostics. At the end these are two things I have changed that have work for me, both turning on Windows 8 features (so go to Win8 and open 'Turn Windows Features On/Off'.
Activate the checkboxes for:
Internet Information Services Hostable Web Core
Internet Information Services > World Wide Web Services > Application Development Features > ASP.NET 4.5
Internet Information Services > World Wide Web Services > Health and Diagnostics > Tracing
Internet Information Services > Web Management Tools > IIS Management Scripts and Tools
That worked for me, it makes sense, as I'm using Visual Studio 2012 and trying to get some trace information using diagnostics in Azure.
I hope this will work for you or give some tip about the problem. In the case of being useful information, remember to vote as response or as value tip.
Thanks,
Mike
This usually happens when there's a problem with the project to be deployed to the emulator (WindowsAzureProject2 in your case).
Try the following:
Check %UserProfile%\AppData\Local\dftmp\IISConfiguratorLogs\IISConfigurator.log file for the error messages. See more details in this answer.
Make sure your project can be started without the emulator. It's a web project, so just try to start it as a regular web project. Or publish it to the separate folder and try to create a website in IIS of it.
Check your *.csdef and *.cscfg files to make sure all the configuration is correct.
Make sure that the build output of your project is not empty. You can do this by going to IIS, find the site with the name similar to deployment16(6).WindowsAzureProject2.WebApplication3_IN_0, right click --> Explore.... Make sure that this folder is not empty and contains all the files required to start a web project successfully.
BTW, there's a similar question: Debugger can't connect when starting local azure project
Follow step 11 from http://www.microsoft.com/en-us/download/details.aspx?id=35448. Worked for me on Windows 8 with Oct 2012 SDk
I just have today the same problem trying to Debug locally with Azure Storage Emulator in Windows 7. So in the Azure project properties, in Web tab, I checked the radio button 'Use IIS Express' and it debugged without problem. I hope this helps someone.
I encountered this exact same problem when I upgraded an existing Azure solution to the Azure SDK 2.1. After some hunting around I uncovered that the upgrade had automatically set the "Local Development Server" setting to "Use IIS Web Server".
Changing the "Local Development Server" setting to "Use IIS Express" fixed the problem immediately.
To access this setting right-click the Azure cloud project file in your solution, select the "Properties" option, tab down to "Web" and you'll see the following setup.
Also, make sure you run Visual Studio as administrator
Please check the version of emulator you have installed. If your code is created in older sdk and you have a new emulator installed it will give you this error.
Check the version of Azure APIs in your project, go to Project > references and right click on Azure dlls to check the version, same sdk version must be installed on the system, higher are optional as azure 2.x are not backward compatible.
I'm using IIS 7.5 on Windows Server 2008 R2 x64 Enterprise Edition. In the project we have developed with ASP.NET 4.0 we used WCF Service. But it doesn't run over domain when the software is running from local computer. Otherwise, I am getting the following error:
HTTP Error 404.3-Not Found
The page you are requesting cannot be served because of the extension
configuration. If the page is script, add a handler. If the file should
be downloaded, add a MIME map.
You should install IIS sub components from
Control Panel -> Programs and Features -> Turn Windows features on or off
Internet Information Services has subsection World Wide Web Services / Application Development Features
There you must check ASP.NET (.NET Extensibility, ISAPI Extensions, ISAPI Filters will be selected automatically). Double check that specific versions are checked. Under Windows Server 2012 R2, these options are split into 4 & 4.5.
Run from cmd:
%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -ir
Finally check in IIS manager, that your application uses application pool with .NET framework version v4.0.
Also, look at this answer.
In my case, along with Mekanik's suggestions, I was receiving this error in Windows Server 2012 and I had to tick "HTTP Activation" in "Add Role Services".
In windows server 2012, even after installing asp.net you might run into this issue.
Check for "Http activation" feature. This feature is present under Web services as well.
Make sure you add the above and everything should be awesome for you !!!
I was having trouble accessing wcf service hosted locally in IIS. Running aspnet_regiis.exe -i wasn't working.
However, I fortunately came across the following:
Rahul's blog
which informs that servicemodelreg also needs to be run:
Run Visual Studio 2008 Command Prompt as “Administrator”.
Navigate to C:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation.
Run this command servicemodelreg –i.