I have to create a pluggable web app at work and I was looking at MEF which is supposed to give all the infrastructure needed for plugin model application, however I see it's still in preview, but I was wondering if anyone has used it on a production application?
MEF V1 shipped.
Related
I'm developing a Service Fabric-based trading platform that will host hundreds of different long-running trading algorithms, all of which conform to a common interface and share a good deal of common code but can be vastly different in their internal specifics. I could model each of the different algos as an application type (which I'd dynamically load) but given the large number of different algos I have to wonder if in makes more sense to create a single Plugin Runner application type then implement the algos as plugins.
In a related question, I understand how to implement a plugin architecture, in general, but I'm not quite sure where one would place the actual plugins in order to be discoverable by an instance running on Service Fabric.
Anyway, thanks for your help....
Both approaches can work I think. Using lots of Application Types adds the (significant) overhead of running lots of processes, but allows you to use and upgrade multiple versions of the same algorithm running simultaneously.
Using the plugin approach requires you to deal with versioning yourself.
Using the Application approach probably requires some kind of request router, while the
plugin service could make it's own decisions (if it's stateless).
You can create a Stateful service that acts as the plugin repository, or mount a file share, or use a database, no restrictions from the platform here. You can use naming conventions to locate the proper plugin.
The following approach could work if an application upgrade is acceptable to you when changing the set of plugins needed for a given application instance.
Recall that Service Fabric apps must be packaged before deployment or upgrade. Using either msbuild tasks or Powershell, you could copy your plugin dlls to the plugin runner service's code package as a post-packaging step prior to the app upgrade. Then your plugin dlls would be available to the service at startup using Assembly.Load and the code package's path, available in your service implementation's Context.CodePackageActivationContext.GetCodePackageObject("Your-Code-Package-Name").Path property. The code package's name is defined in ServiceManifest.xml, and is named Code by default.
Been googling around for some time already.
I have some java, nodejs, php, etc. applications deployed in openshift, and I want to deploy a scala play2.3 app now. I'm starting a new project and I really want to write it in scala with play.
I need either a way to deploy a play 2.3 app in openshift, or another free hosting service that provides the same tools.
Thanks in advance!
Regards
as i know Heroku hosting service let you deploy scala-play application. also it seems that OpenShift also provides the same functionnality.
You may try following QuickStart: https://hub.openshift.com/quickstarts/198-play-framework
I will try to make it simplify. I am using windows azure cloud to host our web services and databases. and these web services are accessible via URL: "https://server.mydomain.com"
now we made a few major changes to our model and hence web services as a whole. This breaks the API interface for older users. Now we want to deploy the latest version on URL: "https://server.mydomain.com/v2" so that old users can still access the older version.
I searched around SO and other resources but i couldnt find a definite answer how to deploy new version without messing up the old version.
Anything in right direction will be helpful.
In one of the projects I was working on, we built in a versioning scheme on top of our Web API. We used this tutorial to get started. I would recommend starting there.
Sorry for the generic answer, if you post some more specifics I will make some updates.
I'd suggest to deploy separate cloud service and use "v2.server.mydomain.com"
I've recently started to develop some sites using orchard, which is great so far, however I'm a bit confused about how to set up my deployment environments properly.
Normally I would set up local dev site, test, staging and live. using web.config transforms to alter connection strings and other app settings
I've recently been using AppHarbor for hosting and I think they are brillant.
There's a guid to setting up Orchard on AppHarbor here
Although I have to agree with comment here about all the post I've read expecting me to want to use and love Web Matrix!
Although most development in Orchard, will be done by creating modules. I think for at least one site they will want at least staging and live environments.
Whats the best way to set up and migrate from one environment to the next?
I've looked at the multi tenancy project, but that seem to address a different issue
I'd be interested to know what other have done. As well as any recommendations for modular Orchard development and in house source control - for those modules only.
I use the import-export module for exporting and importing content in my DTAP environments. Make sure to implement/override Importing and Exporting in your drivers (see: Custom part properties missing in export Orchard 1.6 /plug ;) )
Widgets however should be done manually AFAIK. They don't export and import well with that module.
As for modules and themes: just copy the folder. Same goes for media.
Where I work, we release bug fixes in to the system every night when we know our clients are not using the system.
Trying to take a step towards better service I'd like to deploy to IIS while the application is running.
A solution that comes to mind is to setup two different IIS applications and switch them over after deploy using a script. But I'm not going to try this out as I don't want any complications during our busy hours.
Does anyone have experience in this area of deployment?
Thanks
Regardless of whether you're using PHP, ASP, ASP.NET etc there is no native support for transactional deployment on IIS.
The simplest approach would be to have two physical folders and (optionally two web sites - one production, one test) on your web server, for example:
c:\websites\myapp\dep1
c:\websites\myapp\dep2
Initially your site would have its physical path pointing to c:\websites\myapp\dep1.
When you deploy your latest build you'd deploy into c:\websites\myapp\dep2. Once you're done just switch the physical path of the production site over to this folder. This means you still have the original site and can fall back to it if the new code fails for whatever reason.
The next time you do a deployment you'd deploy into c:\websites\myapp\dep1 and once you're done switch the production site to that folder.
You could optionally have a test site that points to the folder you're deploying to so you can make sure the site works before switching your production site over.
This could all be scripted.
Here's some related reading that may be of interest:
Publishing/uploading new DLL to IIS: website goes down whilst uploading
Is smooth deployment possible with componentized ASP.NET MVC apps?
Rob Conery also had an excellent blog post about the lack of a decent deployment story for ASP.NET application. You should take a trawl through the comments some of which are quite insightful:
ASP.NET Deployment Needs To Be Fixed
Getting Constructive On ASP.NET Deployment