I have deployed a new build on Production server, but I dont see the change in this version. I found out that it was caused due to old version of the DLL file under the temporary ASP.net folder
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files
In DEV environment, I can delete, but in Prod. I have restricted access to delete files inside the ASP.net temporary folder.
Can anyone tell me how can I get the new DLL files recreated immediately after I deploy the new files?
Thanks!
When you add new DLLs to the bin folder, they should immediately overwrite the files in the ASP.NET temp folders. I have myself noticed that sometimes (I assume that happend becuase of concurrency issues) the dlls are not loaded into memory.
If you have access to IIS management console, you could recycle the worker process. That should ensure that new temp assemblies are loaded.
Also if you change aspx oder ascx files, the resulting assemblies should be automatically replaced in the temp folder. If there is the same problem, I recommend recycling the worker process. Maybe you can integrate this in some automated way in your deployment procedure.
Related
I have an ASP.net that I built in VS2010 running in iis7 however when I go back into VS and make updates to the code behind file and re-publish the application still acts as it has before I made the changes. I have tried deleting and republishing all the files and restarting the app pool but it still doesn't affect how the application behaves.
project-->Property's--> Package / product web--> Items to deploy --> All files in this project folders
now publish your project.
your new files also added in publish folder. . .
DO NOT publish your vb and cs file on there server unless you feel like having your source code potentially exposed. There have been multiple vulnerabilities that have allowed code download.
Publish the application to a folder via the visual studio publish menu.
On the server, go into your temporary aspnet folder for example:
c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files
and find your app and delete it. If you cannot delete the files stop the worker process (w3wp.exe) or restart iis.
Republish and all should be good. If you are in doubt if that version is getting executed then add some logging in the new version or trace information.
There are two options for publishing an ASP.NET site to a server:
Copy the .aspx AND aspx.vb (or .aspx.cs) files to the server. The first user to hit the server causes compilation so it takes a little bit of extra time for them. Once that's done, subsequent hits should not be impacted.
Copy just the .aspx files - and a compiled DLL to the server. The DLL contains the compiled code so it doesn't exist on the webserver. The first user does not have to wait for compilation and the VB or C# source code is not on the server, potentially accessible to hackers.
It sounds like you've compiled the site to a DLL but that DLL isn't getting published to the server when you re-publish. Have you recompiled the site before publishing?
I faced similar issue with WPF single file exe publish.
while debugging from VS my changes were visible.
But when I pasted the exe to deployment folder, the changes weren't there.
I had to change the version number to see my changes when I run the exe from the deployment folder.
I may have to do with how single file exes are handled. The extracted cache may not be getting updated.
I've inherited a web app in need of some maintenance and all of the changes I've made happen to be in the global.asax file. A bit of googling tells me that this is dynamically compiled (there is no global.asax.cs codebehind present) so I figured I could deploy the changes by just dropping the new file into the app's root directory. Turns out there is no global.asax file to be found in there, but there is an App_global.asax.compiled in the /bin folder. I can't find this .compiled file anywhere on my dev machine so assume its only created by IIS (and not the asp.net development server).
As an experiment I stopped the app pool, renamed the .compiled file, copied the global.asax to the app root folder and restarted the app pool. After a couple of minutes the .compiled was not regenerated from my new global.asax so I reverted the changes.
How do I get my changes into the live app? The app is pretty big with quite a few dlls so I'd like to avoid doing a full deployment if possible.
Thanks
The presence of the App_global.asax.compiled file tells me that your ASP.NET project is configured to compile everything and not leave the as*x files as editable. i'm not even sure if the .asax file can be left as editable like .aspx files can. But yours is definitely compiled in.
For that reason, I believe you're going to have to recompile and redeploy the whole thing.
Check the bin folder on the server, if it contains App_Code.dll or something similar then it's probably published in debug mode and you should publish the project in precompiled mode and only upload App_code.dll for the changes in global.asax to take effect
You cant directly deploy only Global.Asax. If you want then you can do it by editing DLL. If you are on MVC project then you can see mvcapplication.cs in DLL. There we can apply changes. Its worked for me. I have used .net Reflector with Reflexil 2.1.
DESCRIPTION
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 develop a simple file manager inside an ASP.NET Web site (not web application).
I notice that every time I rename or delete a folder, the site gets recompiled - i.e. the very next web request after delete or rename operation takes considerably much time to execute.
It's only true for folders, not for files.
Why does this occur?
P.S. I use WebDev server (Cassini), haven't tested in on IIS yet.
UPDATE: The same disaster happens with ASP.NET MVC Web Applications :(
UPDATE 2: Here are similar discussions:
Storing temporary user files in ASP.NET in medium trust
ASP.NET restarts when a folder is created, renamed or deleted
Asp.net watches the folders and then runs compilation to keep up with any changes you make. To overcome this you can use Non-updateable full precompilation, which you can read about here.
You should move the files folder outside the project structure and probably use a virtual folder in IIS to keep the paths. This should not only prevent recompilation but will also make updating the code and backing up the user files easier because they will be separated.
Where are the folders you are creating? Under App_Data?
I've discovered this folder in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files and have a few questions.
What does ASP.NET use this folder for, and what sort of files are stored here?
How does a file get stored here, and when is it updated?
Does the folder need any sort of maintenance?
These are what's known as Shadow Copy Folders.
Simplistically....and I really mean it:
When ASP.NET runs your app for the
first time, it copies any assemblies
found in the /bin folder, copies any
source code files (found for example
in the App_Code folder) and parses
your aspx, ascx files to c# source
files. ASP.NET then builds/compiles
all this code into a runnable
application.
One advantage of doing this is that it prevents the possibility of .NET assembly DLL's #(in the /bin folder) becoming locked by the ASP.NET worker process and thus not updatable.
ASP.NET watches for file changes in your website and will if necessary begin the whole process all over again.
Theoretically the folder shouldn't need any maintenance, but from time to time, and only very rarely you may need to delete contents. That said, I work for a hosting company, we run up to 1200 sites per shared server and I haven't had to touch this folder on any of the 250 or so machines for years.
This is outlined in the MSDN article Understanding ASP.NET Dynamic Compilation
The CLR uses it when it is compiling at runtime. Here is a link to MSDN that explains further.
Thats where asp.net puts dynamically compiled assemblies.