I'm using MSDeploy to keep IIS Servers in sync. But, I'm receiving these messages all of the time now:
Info: Deleting binding (MSDeploy.appHostConfig/appHostConfig[#path='Default Web Site']/site[#name='Default Web Site']/bindings/binding).
Info: Adding child bindings (MSDeploy.appHostConfig/appHostConfig[#path='Default Web Site']/site[#name='Default Web Site']/bindings/binding).
I'm just doing the following:
"C:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:apphostconfig="Default Web Site" -dest:apphostconfig="Default Web Site",computername=[removeddestination]
The source server is 2008 and the destination is 2012. Is this normal? Or am I missing something.
I looked at the applicationHost.config files and they are about as close to being the same as I think the can be, realizing that they are different OSes and all.
This is just one example. I have several different updates that it says it's doing, but it really should be the same thing. All of them are of the "Updating Application" variety.
Thanks for any assistance.
Nick
You could try adding the -verbose flag to your msdeploy call to get more details about why its deleting and reading the binding.
Well, I took the -verbose command and added it to my deploy to figure out just what was causing it to show up. Seems almost all of them are items that were added in IIS 8.0. (And I'm on 7.5 of course). So I'll just take that as being an "expected" solution.
Thanks!
Related
I have searched all the usual but come up empty. I must be doing something silly!
Simply I created a new project, ASP.NET Web App, and wish to use and debug it with the local install of IIS 7.5 on my Windows 7 x64 box.
According to what I have read it should be a simple process; my issue is that Visual Studio will not stop at breakpoints nor at errors etc.
I just don't get it:
Visual Studio is attaching to the w3p process for me automatically.
If I hover over the breakpoints it shows a message saying the same, that it is in the same w3p process.
I am in Administrator context. I manually ran it like so to be sure but in any case if you are an admin it runs like that anyway.
Some notes:
I do not wish to use IIS Express as I require native IIS 7.5 for my tasks, however it does debug in express - no surprise there.
As mentioned above, all this is being done locally.
The path of the virtual directory is pointed towards the project files, as set by Visual Studio 2010. It even set the Network Service as read on the folder structure.
When debugging from VS the web site runs fine, just debugging is the issue.
Maybe it is permissions? The Default App Pool is using the ApplicationPoolIdentity not Network Service... Should it be? I had assumed they we.re one and the same essentially. Although I changed this and no luck unless I didn't do something I should of
Keep in mind here that my issue is semi-unique in that I am not receiving error messages, not even in the event logs... For all intents and purposes it should be working fine, just it isn't.
VS and IIS, and all updates, are applied to date.
Note: I'm familiar with IIS7.5, I run my own public web hosting server. I just never tried to debug
Note: It is Visual Studio 2010 Ultimate
Thanks for your time.
Sigh!
I went back to basics... Uninstalled IISExpress and tested; It worked! Re-installed IISExpress; It worked!.
I guess installing IIS7 native after IISExpress did something screwy? I had ran the register ISS command on IIS7 when I installed it.
Right, so now I have both installed in tandem and they work fine. Thanks for all your help guys, appreciated.
you can try right-click on project in VS go to properties select web from left menu tab. Check if ASP.NET debugger is checked and also you can select Use Local IIS Server and give localhost url there (in project Url textbox) and then Say start debugging from VS and put breakpoints.
I had a similar issue the other day, I attached the debugger to the wrong w3p process, make sure you attach it to the one the app pool identity is running under.
I wanted to write it as comment by I don't think I can add pictures..
Are you sure you are running the same version of dll?
Is your breakpoint filled like this?
or hollow like this?
1st go to ,Program and Feature in control panel and then in that turn on or off windows features. and now check all check boxes(activate features) related to Internet Information server & windows service managers. once this is done run your visual studio as administrator and then attach to right w3p process.
The situation is I made a minor bug fix to a class, so they want to just deploy the dll affected. They stopped IIS, replaced the dll in the /bin folder of the iis directory for the web site with the new one I gave them, and started iis again. There are multiple servers, but they just changed it on one to try it out. They are still seeing the same error in the eventlog of the server in question. Looking at the stack trace I can tell it is running the old dll.
They've checked the GAC and don't see it there.
I've checked the dll with reflector to verify I gave them the correct new dll.
This is an asp.net 2.0 website and the server is 2003. I'm not sure how it was deployed originally but it has a copy of the old dll in C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\NAME_services#################\assembly\dl3###################\ and in D:\xxxx\Sites\NAME\Services\obj\Release. Could it be using one of these or building the old one or even just caching it in memory?
Nuke your temporary asp.net folder contents. Not sure why the update didn't automatically get compiled, though.
We had same problem but with minor complications, we have many many sites so a "clearing all temp" and restart IIS is not a good option for us. So we needed to be more selective in what to force a refresh on.
On our QA machine, under ... "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files"
I did a file explorer search for the partial file name of what we are trying to release. The file was found in a folder something like:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\4503212x\ad95664x, so I stopped app pool, deleted the folder, restarted and all was deployed then - great!
But .... We had same trouble deploying to production and the above did not work.
Long story short, the QA app pool was set to "enable 32 bit true", but production was set to "False" so the prod temp files resided in:
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319" instead (\Framework64\ instead of \Framework\ ).
If clearing temp files is not working - double check your frameworks, or look for files to refresh at the C:\Windows\Microsoft.NET folder level and below. you may be surprised.
You don't have to stop IIS to deploy your update, you just copy them over.
Also, if they copied only the DLL but your fix was in the .aspx file, then it won't show up. You should really do a full deployment.
We copied the project source code to a new folder and reopened the solution. This somehow tricked Visual Studio into not using the cached version of the DLL. Wish we knew why this worked, but that resolved it for us.
I moved a site to another server, it worked fine for a a while, but then crashed. I figured out that System.Web.Extensions.dll was missing, so I copied it again. After a while it was missing again.
Using Process Monitor I figured out that IIS (w3wp.exe) deletes the file soon after I copy it to the bin folder. (CreateFile with "Read Attributes, Delete" access.)
What could cause this behaviour?
This is extremely difficult to diagnose without version or error information, but I can offer a few suggestions.
First of all, it is not recommended to put System.Web.Extensions in the bin folder. If the latest framework is installed, the ajax assemblies are included in the GAC and everything is configured to work properly. By dumping a dll in the bin folder, you are experimenting with version, dependency and trust issues which may cause your application to run slower, different or not at all.
Verify your .net framework installations to ensure the most recent version or service packs are installed on both the server and your development machine. Then double check which versions are actually being referenced by your web project and web.config. There has always been a version problem with ajax between development and deployment (expecially during beta cycles) but as far as why the IIS worker process deletes files in this scenario, you have me stumped.
Migrating a project from ASP.NET 1.1 to ASP.NET 2.0 and I keep hitting this error.
I don't actually need Global because I am not adding anything to it, but after I remove it I get more errors.
The reason I encounter this issue is because I change the build configuration. When I set a web project to x86, it changes the output path to bin\x86\Debug. However, the output path should be bin and the web server won't find the binaries because of this.
The solution thus is to change the output path of the website back to bin after you change the build configuration.
There are a few things you can try with this, seems to happen alot and the solution varies for everyone it seems.
If you are still using the IIS virtual directory make sure its pointed to the correct directory and also check the ASP.NET version it is set to, make sure it is set to ASP.NET 2.0.
Clear out your bin/debug/obj all of them. Do a Clean solution and then a Build Solution.
Check your project file in a text editor and make sure where its looking for the global file is correct, sometimes it doesnt change the directory.
Remove the global from the solution and add it back after saving and closing. make sure all the script tags in the ASPX file point to the correct one after.
You can try running the Convert to Web Application tool, that redoes all of the code and project files.
IIS Express is using the wrong root directory (see answer in VS 2012 launching app based on wrong path)
Make sure you close VS after you try them.
Those are some things I know to try. Hope one of them works for you.
I've found that it happens when the Global.asax.(vb|cs) wasn't converted to a partial class properly.
Quickest solution is to surround the class name 'Global' with [square brackets] like so (in VB.Net):
Public Class [Global]
Inherits System.Web.HttpApplication
...
Deleting the existing global.asax file and adding a new one, clears out this error. This has worked for me many times.
If your using visual studio 2010 this error can occur when you change the configuration deployment type. The 3 types are x86, x64 and Mixed mode.
Changing to mixed mode setting for all projects in solution should resolve the issue. Don't forget to delete the bin, Lib files and change the tempdirectory output if your an ASP.NET website.
This just happened to me and after trying everything else, I just happened to notice on the error message that the app pool was set to .Net 1.1. I upgraded the app to 2.0, converted to web application, but never changed the app pool:
Version Information: Microsoft .NET Framework Version:1.1.4322.2490; ASP.NET Version:1.1.4322.2494
This one drove me completely insane and I couldn't find anything helpful to solve it. This is probably not the reason most people have this issue but I just hope that someone else will benefit from this answer.
What caused my problem was a <clear /> statement in the <assemblies> config section. I had added this because in production it had been required because there were multiple unrelated applications on the same hosting plan and I didn't want any of them to be affected by others. The more correct solution would have been to have just used web config transforms on publish.
Hope this helps someone else!
Changing the address's port number (localhost:) worked for me :)
I fixed this error by simply switching from Debug to Release, launch program (It worked on release), then switch back to Debug.
I tried just about everything else, including restarting Visual Studio and nothing worked.
I had this same problem installing my app to a server. It ended up being the installer project, it wasn't installing all the files needed to run the web app. I tried to figure out where it was broken but in the end I had to revert the project to the previous version to fix it. Hope this helps someone...
In my case, a AfterBuild target in the project to compile the web application was the reason for this error.
See here for more info
Removing Language="c#" in global.asax file resolved the issue for me.
In my case, I was duplicating an online site locally and getting this error locally in Utildev Cassini for asp.net 2.0. It turned out that I copied only global.asax locally and didn't copy the App_code conterpart of it. Copying it fixed the problem.
When you try to access the Microsoft Dynamics NAV Web client, you get the following error.
Could not load type 'System.ServiceModel.Activation.HttpModule' from assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
This error can occur when there are multiple versions of the .NET Framework on the computer that is running IIS, and IIS was installed after .NET Framework 4.0 or before the Service Model in Windows Communication Foundation was registered.
For Windows 7 and Windows Server 2008, use the ASP.NET IIS Registration Tool (aspnet_regiis.exe,) to register the correct version of ASP.NET. For more information about the aspnet_regiis.exe, see ASP.NET IIS Registration Tool at Microsoft web site.
try this solution
https://www.youtube.com/watch?v=LNwpNqgX7qw
Ensure compiled dll of your project placed in proper bin folder.
In my case, when i have changed the compiled directory of our subproject to bin folder of our main project, it worked.
Had this error in my case I was renaming the application. I changed the name of the Project and the name of the class but neglected to change the "Assembly Name" or "Root namespace" in the "My Project" or project properties.
Deletin obj, bin folders and rebuilding fixed my issue
I had this problem.
I solved it with this solution, by giving CREATOR OWNER full rights to the Windows Temp folder. For some reason, that user had no rights at all assigned. Maybe because some time ago I ran Combofix on my computer.
Since, for various reasons, I can't use IIS for an ASP.NET website I'm developing, I run Cassini from the command line to test the site. However, after installing Visual Studio 2008 SP1, I get a System.Net.Sockets.SocketException when I try to start up the web server. Is anyone else having this problem, and if so, how did you fix it?
Is there anything in the Application section of the event log?
Have you tried using a different port?
Per this thread, try:
Unbind from Visual Source safe, delete the web project from the solution, rename the folder where the website is stored and then re add to the solution as an existing web site and then bind to source safe again.
There may be some incorrect info in your .suo or .sln file. You can safely rename the former, as it is user-specific (solution user options); the latter (the solution itself) would be a bit more of a hassle to recreate.