Here's the situation: I've got an asp.net webpage who calls Process.Start() to do some work. When I do this on my development machine, it simply works. When I try it on a fresh Windows 7 install, I'm having issues running that other process (which is also a .NET application).
That program depends on, among other assemblies, the OOXML SDK DLL. When trying it on the deploy machine, I'm getting "Access Denied" exceptions when the program attempts to load the OOXML assembly. When trying to simply run the exe instead of doing it by Process.Start, there are no problems and the application works. I've tried settings permissions for IIS's Application Pool, IUSR account and all the basic solutions for usual Process.Start problems. I'm lost, what am I missing?
Some more information:
1) I can't find any differences between IIS configurations for the deploy/develop machines.
2) I've installed the OOXML SDK on the deploy machine but somehow the process still can't load it
When you say you have tried setting permissions, was it on the OOXML folder? You could try checking if the IIS account has read access to the folder where the OOXML dlls are placed.
Related
I have an Asp.net application that handles the function of creating a directory and then viewing that directory (on the network).
Dim di As DirectoryInfo = New DirectoryInfo (Me.lblPath.Text)
di.Create()
Process.Start(Me.lblPath.Text)
Both creating and viewing the directory work perfectly from Visual Studio... but when I run the compiled asp.net application it shows me "access denied" in both cases.
[Win32Exception (0x80004005): Access denied]
The folder where the subdirectories are created is on the network and is shared for everyone.
Please help!
Actually, if you check, the folder probably was created. It really depends on the user you using to run the application pool.
However, then 2nd part?
Process.Start(Me.lblPath.Text)
That is not allowed anymore. Server running process (such as IIS) are in general not allowed to shell launch system apps.
So, you can get your code to create the folders. But, IIS is a service, and such running services as a general rule can't start (shell) execute things like windows explorer in this case.
You might try giving the application pool user rights to do this, but from what I can tell, by default, running IIS services, that service can't start such programs.
You can CERTAINLY do this on your development computer, since you running VS, and it runs + launches IIS express as a context as you the super user and owner of that computer.
but, on a real server, running IIS? Nope, in general this is not allowed. Quite sure this hole was plugged around 2008. In think in server 2012, you COULD set security to make this work (I believe some kind of rights to a console_0 user.
but, after 2012, even that option was removed.
So, such code? Yes, it will work during deployment on your development computer. but a server system, running IIS is locked down, and to my knowledge, you can't execute or run such processes.
Put in a try/catch, and send the error out to a extra text box on that page - you see the web does generate a error.
I have an ASP.NET 4.6.1 application that I am trying to deploy to a remote web server using TeamCity and MSBuild. Below is the MSBuild build step within TeamCity.
When I run the build in TeamCity, it always fails on this build step with a FILE_IN_USE_ERROR. The DLLs that are being updated before the error are usually the same, but sometimes they are different.
[MSBuild output] Info: Updating file (MyApp\bin\roslyn\Microsoft.VisualBasic.Core.targets).
[10:35:23]
[MSBuild output] Info: Updating file (MyApp\bin\roslyn\System.AppContext.dll).
[10:35:23]
[MSBuild output] Info: Updating file (MyApp\bin\roslyn\System.Collections.Immutable.dll).
[10:35:23]
[MSBuild output] MSDEPLOY : error Code: ERROR_FILE_IN_USE [C:\BuildAgent\work\b89cd3dfa447b\MyApp\MyApp.csproj]
I've already read through many articles (here, here, here, and here) suggesting that I drop an app_offline.htm file before deploying so that the IIS can re-route traffic and the file locking issues will stop. I tried that and it doesn't work. I still get the file in use issues during this build step.
I've also read in plenty of other discussions that another solution is to stop the application pool, deploy the app updates, and start the application pool. This is not a realistic solution because the deployment usually lasts between 15 and 20 minutes. Plus, this doesn't allow me to show a nice message to any current users.
I've been reading about this for a while now and it seems like this is a common use case for deployment to an IIS web server. Shouldn't this just work without locking files? Does anybody know of any other solutions to this problem?
I would try by stopping app pool to see if that`s a root cause of the issue.
But I'm not sure why it fails on .csproj file, because usually you don`t deploy those on server. So either it fails on different file (that is actually in use by web application) or it fails during build, not deploy (than app-pool stop will have no affect).
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.
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.
I’m trying to use a (VS 2008) Web Deployment project in a TFS solution to deploy the web site to the (TFS 2008) build server to run web based unit tests.
For some reason, that I can't yet figure out, it is failing to create the virtual directory:
Using "CreateVirtualDirectory" task from assembly "C:\Program Files\MSBuild\Microsoft\WebDeployment\v9.0\Microsoft.WebDeployment.Tasks.dll".
Task "CreateVirtualDirectory"
Initializing IIS Web Server...
C:\Program Files\MSBuild\Microsoft\WebDeployment\v9.0\Microsoft.WebDeployment.targets(667,5): error : Access is denied.
C:\Program Files\MSBuild\Microsoft\WebDeployment\v9.0\Microsoft.WebDeployment.targets(667,5): error :
Failed to create virtual directory 'abc'.
Done executing task "CreateVirtualDirectory" -- FAILED.
The TFSService user certainly is in the Administrators group on the TFS Build machine (which is running Windows Server 2008). I don’t know what else could be wrong. I’ve checked the event log an there’s no clues there. I am able to manually create the virtual directory on that machine through the IIS console with no problem.
Any ideas what could be the problem or suggestions for how to diagnose this further?
it has got to be permissions...did you try putting the TFSService in the same Groups you are in?
Is the TFS account running under the same privileges as the account that you use to connect to IIS? Do as Craig suggested and move the TFS account into the groups that you participate in.
You're sure that the build is running under the TFSService id and not under another id set up just for builds, and which may not be in the administrator's group? I haven't done more than just play with automated builds since I do mostly solo development, but I recall setting up a separate build id when I was looking at this.
I have seen this occur when the IIS server wasn't running on the default port. I'd recommend checking IIS to see if it's running on port 80 as a step to diagnose your issue further.
I eventually managed to get deployment working by calling the _CopyWebApplication build target of the web application from my TFS build script (after manually creating the IIS virtual directory).
I had to add an additional target though to get linked files in the project to be copied also as the built in _CopyWebApplication target doesn't include those.