I'm building an installer with NSIS that will install multiple ASP.NET applications at the same time. I only need to find the physical directory of these applications on the server to install my files.
NsisIIS provides functions to return: web sites, virtual directory and app pools, but nothing to return a list of applications and their properties.
I already know the name of these applications, but the physical directories varies from server to server.
I was wondering if someone had a solution to this problem.
Thx
To solve this problem, you can use the APPCMD.exe, which can do the job for you. Just call it from NSIS like this:
Section "Test"
nsExec::ExecToStack 'C:\WINDOWS\system32\inetsrv\appcmd list vdir "Default Web Site/virtual_path" /text:physicalpath'
Pop $0 ;return value
Pop $1 ;printed text
DetailPrint "output from command: $1"
SectionEnd
You must after all call Pop twice, because ExecToStack stores the return value (%errorlevel%) above the text returned from executed command.
Related
We are trying to create windows services, which’ll run every day at 3 AM in morning. The service basically, removes/delete ASP.NET Temp files.
We were able to find the command line argument to stop/start IIS and delete Temp files. Also, we created a simple windows services.
However, we have couple of issues:
Temporary Folder permission is reset to Read only and we need to manually change it to remove read only permission.
Based on google search we had, we aren’t sure: how to call DOS command from windows services at regular interval. Do we need to use batch file to execute DOS command and if so, then how to do that.
Below is command to stop/start iis and delete temporary files.
iisreset /stop
C:\WINDOWS\system32>del /S/Q "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temp
orary ASP.NET Files\"
iisreset /start
Can anyone guide us? Do we need to use window services or task scheduler to stop iis, remove folder permission and delete temp folder. Sample example/instruction will be helpful.
A windows service is a bit overkill for this. All you really need is a scheduled task to kick off to run your commands and set it to run under the instance of a user that has access to the local IIS_IUSRS group (or any with elevated permissions to that folder.)
For example with powershell:
invoke-command -scriptblock {iisreset /stop}
Get-ChildItem -Path "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files" -Include . -Recurse | foreach { $_.Delete()}
invoke-command -scriptblock {iisreset /start}
The setup a scheduled task like so:
https://community.spiceworks.com/how_to/17736-run-powershell-scripts-from-task-scheduler
And set it to run as a user that has elevated permissions to that folder.
You would most likely want to also add a powershell web request to your sites once IIS comes back up or else the first person to hit the site again after you do this is in for an extended initial load time.
I have two WPF applications in the same solution. One is a configuration helper for the other and needs to be run before the 'big' app is run. In the VS Setup project I have included the Primary Output from both applications.
I want to run the configuration helper during the Commit phase of setup so I added a Custom Action consisting of the Primary Output of configuration helper and marked the Installer Class as false.
When I run the resulting msi, both applications are installed in the same folder as desired, but I then get an error that 'a program run as part of the setup did not finish as expected.' The msi then uninstalls.
I was hoping the configuration helper would be kicked off as the msi exits, but would also be happy with the installer hanging open until the configuration helper exits.
What am I missing?
The program you ran as a custom action has failed, probably crashed. It may need some extra error checking or tracing to see what's going on. Programs that run as custom actions are not in the same environment as running them from the interactive user's desktop. The working directory is probably not what you expect (so file paths must be specified in full) and it's probably running with the system account, because that's the way Everyone installs work, so any assumptions about user locations (including the interactive user's desktop, user folders, access to the network, access to databases, ability to show forms) will be wrong and are likely to be failure points. It's better to run configuration tools like this when the app first starts because you are now running in a normal user environment.
I have a production website that, once built in TFS is re-deployed and updated using xcopy. The entire site (excluding the root directory) it deleted then the new site copied in. This works well.
We use a 3rd party charting package that creates images at runtime and then renders a link to them. In order to do this it needs write permissions to a browsable folder.
Unfortunately, every time we update the website the write permissions of IIS_USRS is lost. Is there any way to retain this?
I guess it depends on what operating system the server is running, and whether you are building on the same server as you're deploying to, or a remote one.
The simplest thing to do is to put your xcopy command into a batch file, and include something like the following after the xcopy:
cacls c:\[PathToWebsite]\[ChartImagesFolder] /E /G [AccountSiteRunsUnder]:C
Or a more up to date option (I've not used this, so my parameters may be off):
icacls c:\[PathToWebsite]\[ChartImagesFolder] /grant [AccountSiteRunsUnder]:M
Basically, either of those should give the user account that the site is running under modify (change) rights in the folder specified. This should be in addition to any existing rights on the folder, there are modifiers or switches to replace the existing rights.
If you are deploying to a remote server, you'll need some mechanism to run commands on there, we've found that PSExec works a treat (part of the PS tools from SysInternals).
I want my ASP.NET page to shell out and execute git commands. I put the commands in a bat file which works:
REM cd to the git repo folder
cd c:\temp\mygitrepo
"c:\Program Files\Git\Bin\git.exe" show c090dc4b8b1b3512c1b5363c371e21d810d02f54 -- myfile.txt
If I run my .bat file from a cmd prompt, no problem.
If I run it using System.Diagnostics.Process.Start, I get this error:
RUNTIME_PREFIX requested, but prefix computation failed. Using static fallback
The error is coming from this git file: http://github.com/git/git/blob/master/exec_cmd.c
I use exactly the same technique to run svn.exe commands, no problem.
EDIT 1: From the thread here I've learned that msysgit installs some files in a location associated with the current user, me, instead of all users. The IIS web server is running under another user account. I tried copying some of the git files that caught my eye, like .gitconfig, to other users (in Documents and Settings). No luck. So, I have switched my focus to getting IIS to impersonate me when it launches the git command.
Is it actually an error, or is it just notifying you of a fallback? Based on the code linked, it appears that the command should still execute successfully, only using the static PREFIX rather than the RUNTIME_PREFIX.
If the command is indeed failing, you might want to make sure that any required environment variables are available when starting the process from .NET. You might also need to impersonate a different windows identity to run the command with proper permissions (I am assuming that the ASP.NET identity is restricted as much as possible.) The ProcessStartInfo object provides a few ways to configure the process, including the windows identity, the process verb, and environment variables. Make sure you are providing the proper context that your batch file requires before running it.
I am running an asp.net application (VS2008/.net 3.5) and when running it under VS in debug more it works fine.
It reads files and directories from a network share happily.
I can run "cleartool startview [dynamic view name]" ok, I can "cleartool mount [vob]" happily.
But if I try to test for the existance of a file within the vob it can't see it.
So I tried something different, I now run "cleartool ls -short -vob_only [filename]" to test for existance.
For both of those it works fine running under VS2008 but won't work when running under IIS post deployment.
I have the set and the user has valid access to ClearCase.
Any ideas?
If you use the built-in webserver (Cassini) during development the webserver is running as you and have access to your networked drives etc. IIS on the other hand uses a different user account and doesn't share your user profile including your ClearCase views etc. That may explain your problems.
I found the problem and a resolution to this. The problem is that ClearCase is using the process user for authentication whereas the shared drive access mentioned in the original question is using the thread user.
The reason for this is the when accessing ClearCase it spawns off a new process - and child processes always use the parents process security context and not the current thread's.
The way around this was to run the web application within its own application pool which is running as a user with rights to access ClearCase. An inflation of rights beyond what should be really necessary however it did the trick.