I have an asp.net mvc 4 application working with a simple dependency being resolved by autofac. The dependency in this case is an IEmailSender whose implementation I want to vary based on development vs test vs production builds. For example, the development(debug) build would send the email using one implementation, but production uses say amazon SES to send email.
What is the best practice way to vary the container dependencies in the global.asax file based on environment? I know I can use web.config transformation with web deploy and then read the web.config value to determine the environment and then "switch" the build configuration based on environment, but maybe there is a better way?
I would recommend the way you have described using the web config and environment transforms, as this is its primary purpose - to determine behaviour in different environments. You may also end up with more environments that just debug (test) and release (production).
The alternative could be to use conditional build statements like [Conditional("DEBUG")]. I would not recommend this approach however as you run out of build configurations pretty quickly if suddenly you have a new environment.
Related
I am working on an asp.net solution and using my remote testing environment with godaddy.
The application is ready for deployment so i have two questions:
1- since the database will be different , i am thinking about using a different Web.config , but not sure how does it work and how to implement that so i can choose easily which web config depending on the poriject/solution
2- the solution i am working on could be personalized and deployed to multiple clients , so each client version will be different (Like the logo and other stuff not the design and functionality), do i need to create separate solution for each client or should i create a separate website project instead?
what's best practices in this case
Use configurations and associated config transforms. By default, your project gets a Debug and Release configuration, but you can add additional configurations. Then, for each configuration, you can have a separate Web.config transform, Web.Server1.config, Web.Server2.config, Web.Client1.config, Web.Client2.config, etc. When publishing, you choose which configuration you want to publish with, and that associated transform will be run against the Web.config file to change out connection strings, app settings, whatever.
For more information see: How to: Transform Web.config When Deploying a Web Application Project | MSDN
I am working with a .net MVC4 web application. I use publish profiles to publish my application and all works nicely.
I transform the web.config, I set up a publish profile for each of the environments I am deploying to qa, production etc. The transform works perfectly when I build the package for particular environments.
Within my web application, I have number of other xml files that vary per environment. Is it possible to also transform these files for deployment? And if so, how might this be achieved?
I believe SlowCheetah was designed for this purpose.
I've created a basic website using the Orchard CMS, and attempted to deploy it to my shared host, Softsys, using Web Matrix (via FTP). Currently, the site technically "works", however it looks like all styling has been removed (even from the dashboard).
Is there a step or files that I missed while deploying the site? I know "Web Deploy" is probably the preferred method of deploying, but I'm pretty new to this, and was not sure what the login specifics were, or how to obtain them for web deploy.
Here is a screenshot of what the site currently looks like deployed:
Edit: it turns out that the problem was on my host's side, for some reason the virtual directory was not being created properly - I still am curious what the proper/best practice method to deploying is however.
It looks like you have no theme applied. Check whether you have your theme existing in ~/Themes folder and properly enabled in the admin Dashboard. Maybe the /Themes folder content hasn't been copied?
UPDATE
If your hosting provider allows the option to deploy sites via WebDeploy - that would be the best one.
The easiest and most straightforward way to deploy Orchard site is to:
Have the ASP.NET application properly configured in IIS and accessible. If you use hosting - provider does that for you. If you'd have a dedicated server - you have to set up an application yourself.
Grab the deployment package from Codeplex, or build one from the sources.
Copy the whole package to your site's root (via FTP or WebDeploy).
Run it and proceed with the setup.
Basically - these are the same steps as for every "ordinary" ASP.NET application.
You probably need to set IIS user to have write access to some of the folders: Themes, Media and App_Data.
When you start a new project (whether it's personal or professional) what do you have at hand to quickly start developing the project?
For example, when I start a new project at work, I have the following already setup from a custom sandbox:
Two different authentication classes, LDAP and CAS which I can change via app.yml
Custom form widgets which I use across most applications
Capistrano deployment script for deploying the project to staging or production servers.
A mail template class which uses an XML file for the templates to send emails
Mail server, ldap etc. settings all configured.
Bunch of icons and the same CSS (which with some exceptions is always the same for each project)
custom error pages, layouts, login layout etc.
static pages such as about, contact us etc.
Useful plugins such as sfFormExtraPlugin, twig etc.
jquery and jQuery UI libraries
Basic local ACL and translation model classes and some other default models.
Tasks - send email task and build translations.
custom tools class for doing some custom stuff
custom factories and some default routes
helpers which I will most probably use are enabled by default (i18n, partial etc.)
And some other things :-)
I'm just wondering what you do to make your development quicker and more efficient when starting a new project. Hopefully I'll learn some new things from what you do.
Thanks folks!
Great question and great list. Here's some more:
As a general practice, whenever we develop a feature that could be used across projects, we develop it as a plugin so it can be easily dropped into other projects.
Custom form formatter that uses our own widget/validators in place of the default Symfony ones.
Custom mailer with support for sending processing templates as emails and better HTML email support.
Plugin for minimizing/combining CSS and JS assets.
Symlink from web/sf to lib/vendor/symfony/data/web. Better than an alias in apache.
Custom admin generator templates.
Quick setup script that takes commandline options or read a config file to create full local dev env (init the project, setup a vhost, modify etc/hosts, import to svn, create svn externals for Symfony and key plugins like sfDoctrineGuard)
Custom Project skeleton
Custom Javascript helper based on Apostrophes new a_js_*() helper functions
For IIS6 I can use the IIS helpers in Wix to install a web application like this:
<iis:WebAppPool
Id="AP_MyApp"
Name="My Application Pool"
Identity="networkService" />
<iis:WebApplication
Id="WA_MyApp"
Name="MyApp"
WebAppPool="AP_MyApp">
<iis:WebApplicationExtension
CheckPath="no"
Executable="[NETFRAMEWORK20INSTALLROOTDIR]aspnet_isapi.dll"
Verbs="GET,HEAD,POST"/>
</iis:WebApplication>
Unfortunately, this doesn't work for IIS7. We don't want to use the aspnet_isapi.dll mechanism, and instead want the integrated pipeline to handle the request routing. The app pool created by this script is in Classic mode not Integrated mode so none of the handlers get run correctly.
How can I correctly install an MVC app on IIS 7?
I personally recommend using AppCmd.exe (matthewthurlow's first bullet) because you don't have to count on the legacy management components being installed, or risk modifying the configuration XML manually.
If you are not comfortable with AppCmd, Mike Volodarsky has a great article on Getting Started with AppCmd.exe, and the Microsoft IIS Configuration Reference is excellent, offering UI, Code and AppCmd examples for modifying each of the configuration items (e.g. Application Pools ). The IIS7 Administration Pack also includes a Configuration Editor that allows you to generate AppCmd scripts from any existing configuration.
To integrate AppCmd into WiX, you need to create and schedule two custom actions for each command. There is general information in the WiX v3 manual documenting this procedure, and I've included a concrete example below.
First, you need to set up an immediate action to store the command line in a property:
<CustomAction
Id="CreateAppPool_Cmd"
Property="CreateAppPool"
Execute="immediate"
Value=""[WindowsFolder]system32\inetsrv\APPCMD.EXE" add apppool /name:"[APP_POOL_NAME]"" />
Next you set up a deferred action which references this property:
<CustomAction
Id="CreateAppPool"
BinaryKey="WixCA"
DllEntry="CAQuietExec"
Execute="deferred"
Return="ignore"
Impersonate="no"/>
And finally, you need to schedule these. The immediate action that sets the properties seem to work well after InstallFinalize, and the deferred action works after InstallFiles. I haven't got as far as figuring out rollback actions yet.
MapGuide Open Source does this method extensively; you can see the CA scheduling in our MapGuide.wxs file, and the CA definition in our IIS7.wxs file.
Thanks to #matthewthurlow, I was able to use the XML utils to achieve what I needed to do:
<util:XmlFile
Id="ModifyAppPoolPipelineType"
Action="setValue"
ElementPath="//configuration/system.applicationHost/applicationPools/add[\[]#name='My Application Pool'[\]]/#managedPipelineMode"
File="[WindowsFolder]System32\inetsrv\config\applicationHost.config"
Value="Integrated"/>
The rest of the actions do seem to work fine with IIS 7.
The IIS extensions for WIX don't support IIS7. The IIS team keep rewriting the metabase between versions. There are quite a few things that don't work, the lack of an integrated app pool amongst them.
Until the extensions get rewritten, you're left with three options:
Use build in custom actions to invoke appcmd.exe
Use XmlConfig to update applicationHost.config
Write your own custom actions
I've opted for the xmlconfig option at the moment as you can do this within a component and tie it to a feature.