Using Visual Studio 2008, I have published my ASP.NET website to my local disk in preparation for deploying to our test server. Using an RDP session, I've connected to the test server running Windows Server 2003, making my local disk available as a resource to the RDP session. When I attempt to copy the files from my local disk to the server, everything copies without issue except for the DLLs in the bin folder. Every time I try to copy a DLL I get the following error: "Cannot copy [filename]: Access is denied. Make sure the disk is not full or write-protected and that the file is not currently in use." I am able to copy any file outside the bin folder and any file except DLLs in the bin folder (such as .compiled files).
It's been a while since I've worked with IIS and ASP.NET so I'm admittedly a little rusty but I've tried everything I know of to fix the issue. I checked the obvious, there's 3+ GB free on the disk, and the file is not write-protected.
I've also tried everything I can think of to make sure the files are not in use. I tried recycling the application pool, restarting the default web site, both restarting IIS and stopping/starting IIS using the GUI, ending the w3wp.exe process in task manager, Shift-deleting the file, deleting from the command prompt, having two other users attempt to delete the files using their login credentials, and restarting the server twice. Nothing at all has worked so far and I'm at my wit's end.
Hoping someone has any suggestions on what else I can try to fix this, any help would be much appreciated.
Try stopping IIS from the command prompt, then restart and after restarting confirming that IIS is still stopped.
After confirmation of the above, zip the files, copy the zipped file over to your server and unzip. Run AV on the files, and you may need to "unlock" the zip.
Related
I have a .NET Core 3.1 app (api) that i'm publishing online and I'm using the publish method FTP in Visual Studio.
It works perfectly but when I try to publish again after coding, I always get these errors:
Publishing folder /...
Unable to add 'AutoMapper.dll' to the Web site. The process cannot access the file because it is being used by another process (550).
Unable to add 'projectname.API.dll' to the Web site. The process cannot access the file because it is being used by another process (550).
Unable to add 'projectname.Domain.dll' to the Web site. The process cannot access the file because it is being used by another process (550).
...
This goes on for quite some time on all the dll's in my project. The only way I can publish after working, is full resetting my PC, remove all bin and obj folders in my projects that have to get published, open VS and publish before doing anything else.
I suspect this has to do with VS still using the dll's somewhere/somehow while i'm trying to publish.
I have tried locating processes in task manager but haven't seen anything unusual/problematic that could cause this.
Any help regarding this would be greatly appreciated, because I like to update my API for every route I write to test on the deployed version aswell, but it's quite the hassle this way...
Thanks!
I don't think it's your pc. Error 550 is an FTP error. What I think is happening here is that when you publish your website via FTP and open your website in your browser what you actually do is run your application on your server.
When your application is running you can not modify the DLLs that are in use.
So why restarting your pc will fix the problem? It is because these hosting providers have a configuration that if no one requests a website for a while then kill the application. it is because of saving memory and cpu.
So when you restart your pc and delete bin and obj folders and rebuild your project that takes time and because in the meantime there is no request sent to your website your application is killed and now you can update your website with FTP again.
To test this scenario simply close your browsers and do not open your website for a while like half an hour and then try to update your website via FTP.
Or you can restart your PC and delete bin and obj folders but before pushing your files with FTP open your site in a browser. This must run your application and cause the 550 error again.
I have a Web Site Project, which actually runs in 32-bit enabled app pool, .net 2.0, IIS 7.5, Windows 7.
Here is the scenario that failing (but most important how it is failing). I pre-compile this site for x64 using aspnet_compiler.exe. I created new, 64bit-only app pool and I set a virtual directory where code is pre-compiled. I do this a lot, so everything as usual, only usually I test 32-bit version of code.
Once I try to access my website through url (http://localhost/mysite/login.aspx), my files in my virtual directory start to disappear. I open windows explorer and I can literally watch how files are being deleted. And then, they are gone and I get 404 response.
Has anyone seen anything like it?
Hopefully, someone will benefit from my experience.
What was happening, I took the code base which didn't contain web.config file. And the w3wp.exe [according to procmon] was deleting the entire virtual directory when web.config wasn't there. Here is how I found out - I enabled 32-bit execution and I immediately received web.config errors on the page. I went to fix it and the file wasn't there. I posted the file and now it was giving me "incorrect format" exception, which was normal since my code base was in fact 64-bit. So, I disabled 32-bit execution on the app pool and everything worked.
The bizarre behavior was that with no web.config w3wp.exe was removing entire virtual directory.
I have a ASP.NET site running locally (localhost) on my Windows 7 computer. I have an error when loading one of the pages. The error is in an aspx.cs file and I can see how to fix it easy enough. But when I edit the source file nothing changes.
So I notice that on my machine the path to the file is C:\intetpub\wwwroot\folder\codefile.aspx.cs
But on the error message the path is e:\intetpub\wwwroot\User_Sites\folder\codefile.aspx.cs
I realize this must be a virtual directory used by the IIS (I assume) but cannot figure out why editing the code file on C: does not lead to it being loaded into the virtual directory when I run it.
I do not have a physical e: drive or User_Sites folder anywhere.
I realize this is probably a simple question but perhaps someone could point out a reference that explains this, or provide a simple explanation?
That means that the web server is using a version of the application that was built using the sources in e:... and not the version you are working on.
Try:
stopping the WWW publishing service
deleting the contents of C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files
deleting the bin folder of your application
building the application
start the WWW publishing service.
This is more a 'why does this work this way' than a 'how do I make this work' sort of question.
I have a WCF web service I am debugging remotely. It is deployed to a staging server where the VS 2010 remote debugger is installed and running as a Windows service. The permissions are correct, I can attach to processes without any problem. The issue I ran into is I couldn't consistently get the symbols to load.
I have the WCF service deployed to C:\Webs\MyService, with assorted DLLs in C:\Webs\MyService\bin. It is set up as a separate site with its own app pool. What I found is even if I had the necessary .pdb file in the bin folder, Visual Studio wouldn't load any symbols when I attached to the w3wp.exe process from my local machine. What was happening is when IIS started and the worker process was spawned, my service DLL would get copied deep under the temp ASP.NET files directory, into something like C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\19f82539\e55fff8f\assembly\dl3\2926a261\f625d158_f62ecd01. I found that if I manually copied the .pdb file to this folder, then symbols would be loaded and I could do the debugging.
I'm wondering why the heck it works that way, and how I can avoid having to manually copy the symbol file to this other directory. What's worse is if I had to make changes and redeploy, the worker process wouldn't recognize them. I had to restart IIS which caused a different temp directory to be created, requiring me to copy the .pdb again.
I have a similar problem, with web applications. Apparently Microsoft are aware of this: http://go4answers.webhost4life.com/Example/remote-debugging-symbols-not-loaded-207525.aspx
Hopefully, they will release a fix soon.
There is also a suggestion by BrianR on a related question, Why are no Symbols loaded when remote debugging?, saying to create a folder with the debug files and on the remote server to point the environment variable _NT_SYMBOL_PATH to it.
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.