We have an ASP.NET website that we want to deploy (and remove) multiple instances of the site on the same IIS machine.
We also have a few number of customers that need to install the product on their system.
I was hoping WIX would be able to handle this, but it appears you can only have one instance installed at a time.
What options are available to me? Right now we use FinalBuilder to setup a generic "install package" which uses a batch file that a user populated with their environment settings, and uses tools like sed and awk to update config files and more scripts to deploy to IIS.
It works, but it's very cumbersome. I was hoping to find more of a GUI/command line interface to replace this process.
It sounds like MSDeploy will work for your use case. It can deploy multiple instances to the same IIS instance and can also delete instances.
The following post is specifically about service versioning but you could use the same technique to install several instances of a web app.
http://www.dotnetcatch.com/2016/03/03/simple-service-versioning-with-webdeploy/
What is the best practice approach to local user generated content when using Microsoft WebDeploy and Team City to deploy fixes to a site?
Using the deployment process described by Troy Hunt:
http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_26.html
When changes are made to a site the WebDeploy agent updates the site including removing old files that are no longer needed - which is great. However in the case where a site contains user generated data (say users can upload an image which is stored as a file on disk or a simple CMS where page content files can be updated by the user), what is the best practice to prevent these files being deleted by the deployment agent?
Is there an ignore flag for certain folders?
Should the user files be stored outside the root of the deployed website (Is this a security risk)?
You basically need to use MSDeploy's skip rules. This will tell MSDeploy to ignore certain files, folder, or subfolders etc.
It depends on where you implement these to what the syntax will look like. But you have the following options:
If your publishing through VS.Net using a publishing profile you can include skip rules here (I've taken this approach and seen it work fine). This SO question should point you in the right direction - MSDeploy skip rules when using MSBuild PublishProfile with Visual Studio 2012
If your using a vs.net web solution (website / web application) I later found out you can also implement skip rules in the web.config. Although the following article is a bit old the approach may still be viable - How to write skip and replace rules for MSDeploy (I havent used, or tested this approach)
Last, but not least, you could use MSDeploy skip rule on the command line itself. So assuming you execute msdeply directly (as opposed to via msbuild) you would need to append a skip parameter with the relevant attributes you require. Further information can be found at: Demystifying MSDeploy skip rules or Web Deploy Operation Settings (Look for the skip command reference, about 2/3 down the page) (Using publishing profiles with MSBuild ultimately makes this call for you, i've seen it in action working by using the first approach above).
Hope that helps!
When I deploy my web site I need to:
Take the site offline.
run sql to update the database.
update the web site.
Put the site back online
I would like to script as much of this as possible without have to go the server and make manual changes.
I am currently using WebDeploy to push my website changes. It works great, and I don't have to know exactly where my site is installed on the server.
So what is the best way to put up/take down the app_offline file? If have seen some solutions where you rename an existing file ( app_offline.htm_ ) using an msbuild script. But it seems like that would require me to know the location of this file.
Is there a way to do this through web_deploy?
Thanks
Yes, you can enable AppOffline during a WebDeploy deployment you can even customize the AppOffline template:
msdeploy.exe -verb:sync -source:iisApp=sourceApp -dest:iisApp=destApp,appOfflineTemplate="offlineTemplate.htm" -enablerule:AppOffline
https://blogs.iis.net/msdeploy/webdeploy-3-5-rtw
Log4Net doesn't write when iis hosting a WCF Service.
it works great when i use the self hosting ( Visual Studio Development Server),
but when i run it using the IIS it doesn't write anything.
i read about this prolem and the conclusion is that
it must be a permission problem, but i don't know how to solve it.
how can i check that i have a permission to write a log file?
where can i change the permission? change AppPool users?
Can you give me some simple steps of how to check if i have a permission problem?
i'm an administrator on my computer.
i'm trying to create the file in the project folder.
The file is a rolling file appender.
thank you.
For my IIS hosted WCF services with HTTP endpoints, logging to App_Data has proven to be the easiest solution.
<file value="App_Data\log.txt"/>
You need to make sure the AD user that the application pool is running under has create/read/modify privileges to the directory where you're outputting your log files. By default, as far as I know, your app-pool user can't create/modify files. So it sounds like you're on the right track.
Edit: Here is an article to help you determine who your app-pool is running as, if needed.
I ran into a similar situation with Enterprise Library not writing to a file using the Logging Application block for an ASP.NET application. This was EntLib 4.1, the eventual solution after trying ACL modifications was to assign the App Pool to run as Network Service and the text logging commenced, not saying this is your solution, or the best one, but its worth a try.
From my experience, in IIS 7+ you have to make sure the application pool has permission to write in the particular log directory. For example,
The problem was solved when i moved the path of the log from "c:\Log.txt" Hard drive to "c:\log\Log.txt" folder in the hard drive.
Where would you write an error log file, say ErrorLog.txt, in Windows? Keep in mind the path would need to be open to basic users for file write permissions.
I know the eventlog is a possible location for writing errors, but does it work for "user" level permissions?
EDIT: I am targeting Windows 2003, but I was posing the question in such a way as to have a "General Guideline" for where to write error logs.
As for the EventLog, I have had issues before in an ASP.NET application where I wanted to log to the Windows event log, but I had security issues causing me heartache. (I do not recall the issues I had, but remember having them.)
Have you considered logging the event viewer instead? If you want to write your own log, I suggest the users local app setting directory. Make a product directory under there. It's different on different version of Windows.
On Vista, you cannot put files like this under c:\program files. You will run into a lot of problems with it.
In .NET, you can find out this folder with this:
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)
And the Event Log is fairly simple to use too:
http://msdn.microsoft.com/en-us/library/system.diagnostics.eventlog.aspx
Text files are great for a server application (you did say Windows 2003). You should have a separate log file for each server application, the location is really a matter of convention to agree with administrators. E.g. for ASP.NET apps I've often seen them placed on a separate disk from the application under a folder structure that mimics the virtual directory structure.
For client apps, one disadvantage of text files is that a user may start multiple copies of your application (unless you've taken specific steps to prevent this). So you have the problem of contention if multiple instances attempt to write to the same log file. For this reason I would always prefer the Windows Event Log for client apps. One caveat is that you need to be an administrator to create an event log - this can be done e.g. by the setup package.
If you do use a file, I'd suggest using the folder Environment.SpecialFolder.LocalApplicationData rather than SpecialFolder.ApplicationData as suggested by others. LocalApplicationData is on the local disk: you don't want network problems to stop you from logging when the user has a roaming profile. For a WinForms application, use Application.LocalUserAppDataPath.
In either case, I would use a configuration file to decide where to log, so that you can easily change it. E.g. if you use Log4Net or a similar framework, you can easily configure whether to log to a text file, event log, both or elsewhere (e.g. a database) without changing your app.
The standard location(s) are:
C:\Documents and Settings\All Users\Application Data\MyApp
or
C:\Documents and Settings\%Username%\Application Data\MyApp
(aka %UserProfile%\Application Data\MyApp) which would match your user level permission requirement. It also separates logs created by different users.
Using .NET runtime, these can be built as:
AppDir=
System.Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)
or
AppDir=
System.Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
followed by:
MyAppDir = IO.Path.Combine(AppDir,'MyApp')
(Which, hopefully, maps Vista profiles too).
Personally, I would suggest using the Windows event log, it's great. If you can't, then write the file to the ApplicationData directory or the ProgramData (Application Data for all users on Windows XP) directory.
The Windows event log is definitely the way to go for logging of errors. You're not limited to the "Application" log as it's possible to create a new log target (e.g. "My Application"). That may need to be done as part of setup as I'm not sure if it requires administrative privileges or not. There's a Microsoft example in C# at http://support.microsoft.com/kb/307024.
Windows 2008 also has Event Log Forwarding which can be quite handy with server applications.
I agree with Lou on this, but I prefer to set this up in a configuration file like Joe said. You can use
file value="${APPDATA}/Test/log-file.txt"
("Test" could be whatever you want, or removed entirely) in the configuration file, which causes the log file to be written to "/Documents and Settings/LoginUser/Application
Data/Test" on Windows XP and to "/Users/LoginUser/AppData/Roaming/Test on Windows Vista.
I am just adding this as I just spent way too much time figuring how to make this work on Windows Vista...
This works as-is with Windows applications. To use logging in web applications, I found Phil Haack's blog entry on this to be a great resource:
http://haacked.com/archive/2005/03/07/ConfiguringLog4NetForWebApplications.aspx
%TEMP% is always a good location for logs I find.
Going against the grain here - it depends on what you need to do. Sometimes you need to manipulate the results, so log.txt is the way to go. It's simple, mutable, and easy to search.
Take an example from Joel. Fogbugz will send a log / dump of error messages via http to their server. You could do the same and not have to worry about the user's access rights on their drive.
I personally don't like to use the Windows Event Log where I am right now because we do not have access to the production servers, so that would mean that we would need to request access every time we wanted to look at the errors. It is not a speedy process unfortunately, so your troubleshooting is completely haulted by waiting for someone else. I also don't like that they kind of get lost within the ones from other applications. Sure you can sort, but it's just a bit of a nucance scrolling down. What you use will end up being a combination of personal preference coupled along with limitations of the enviroment you are working in. (log file, event log, or database)
Put it in the directory of the application. The users will need access to the folder to run and execute the application, and you can check write access on application startup.
The event log is a pain to use for troubleshooting, but you should still post significant errors there.
EDIT - You should look into the MS Application Blocks for logging if you are using .NET. They really make life easy.
Jeez Karma-killers. Next time I won't even offer a suggestion when the poster puts up an incomplete post.