I have a windows service that loads multiple "handlers" written by different developers. The windows service exe has it's own app.config which I need.
I'm trying to make it so that each developer can provide their own app.config along with their handler code. However, it seems an exe can only have one app.config. However, ASP.NET seems to support nested web.config... That's not exactly what I want, but I don't even know how I would get that to work in a windows service.
Anyone come across this before or have any ideas?
I've not tried it, but I think you may be able to use the Configuration Manager to create separate Configuration objects for each of the handlers. Specifically, this page details a method for loading Configurations from "custom" filenames.
Related
I have a Service Client Library project which has its own
app.config
.
This project is referenced in my Web Application. The problem is My web application throws following exception
Could not find endpoint element with name 'HttpEndPoint' and contract 'ServiceLibReference1.IDalService' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this name could be found in the client element.
There is nothing wrong with the service. If i directly refer my service in the web application it works fine as client configurations get added to the web.config. But my requirement is to keep it in a separate library project.
The reason for the exception is service configurations are not added to the web.config. Should i always add them manually? Should not VS add corresponding configurations into web.config whenever a service library is referenced? or am i missing something ?
thanks
Service libraries are, by design, intended to be used by (potentially) multiple different applications. Therefore, they don't use the app.config file included in the template - they will use the config file (web/app) of the application that is referencing them. This promotes code reuse - if you have certain methods that you are always using across multiple applications, it's easier to put them in a separate class library assembly. One benefit of that design is that you only need to change the code in one place to make the change effective for all using applications.
So yes, you will always need to add the service configuration to the specific application configuration file. Unfortunately, VS does not know to do this.
This seems like a pretty common use case, but I can't for the life of me find any information on how to set this up.
I've got an "Admin" site where I upload images and then my normal website (separate project) where I need to display those images. Both projects need to be able to display the images (so I can't just simply store them in the website's project directory and call it a day).
In production, this is a no-brainer. I just set up a virtual directory in IIS, but developing in Visual Studio, there's no direct support for this. I've seen things online that tell you do go into the IIS Express config files and add the virtual directory manually, but there's two huge problems with this: 1) I'm in a multi-developer environment and making every developer do this in a consistent way manually is a no-go and 2) there's no automated way to reference this static directory in my code, so that's going to entail a lot of hard-coding paths to image references, which is a hugely bad idea.
I'm aware, also, that I can create links in my project, but I'm dealing with uploads, not static resources that I know about at design time, so creating links for every new upload manually in my project (especially when this is only for testing in development) is insane.
So what is the best way to dynamically share resources between projects just for the purposes of development in Visual Studio?
For what it's worth, these are both ASP.NET MVC 4 projects and I'm using Visual Studio 2012 on a Windows 7 box.
EDIT I should specify that upon uploading the image, a relative path to that image is stored in a database table. I suppose my real issue is in resolving that partial path into a real accessible URL from an entirely different project. If I was in the same project, I would simply to something like Url.Content(Model.ImageUrl), but this obviously won't resolve if the image is not actually in the same project.
It was pointed out to me that I'm over-thinking this.
In production, the files would of course be served through some virtual directory, but in development, it doesn't matter where they're served from. So, all I really need to do is add an app setting for the static URL prefix to prepend to the relative image URL.
For development it would just be the localhost + port of my admin site.
Then, in my release web.config transform, I would just change it to the production URL, i.e. something like "http://static.mydomain.com". In my app code, I just look up this app setting and prepend it to my relative image URL and I'm golden.
If I run into any problems with this approach, I'll note them here with appropriate solutions, once I get a chance to actually implement it.
I want to be able to have a folder which allows regular access like the \content folder except that it holds a ClickOnce application. I can't seem to be able to achieve this using Mvc, but I'd like to have this folder accessible without Mvc seeing it as a controller action.
I tried using routes.Ignore(theUrl), but this seemed to have no effect.
There are two ways you can do this. The first is where you are currently going, which is to satisfy it with routing. You should be able to use the following to ignore the intended route:
routes.IgnoreRoute("...")
However, this might not be the right approach from a security stand point. I would recommend you define an explicit action to download your click-once exe. Have a look at this q/a as an example of using the FileContentResult class.
The reason for this is that you can control security for that file without having to open up access levels to other directories.
Edit: If this is for an entire directory, you can still follow this same approach.
Set up the folder as a virtual folder in the website on IIS. then you can set the url in the code to point to the machine serving the request and to the virtual folder on the web server.
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.
What is the best practice for sharing the assemblies of a bin folder across multiple ASP.net websites in IIS 7?
I've got several sites, each with slightly different HTML front ends, but all with the same middle tier logic and DB. I don't want to redploy the same dlls to each of the many site's bin folders everytime I make a change.
Thanks.
Yes, actually, you do want to deploy them individually. That's how it works.
If this truly offends you, then consider whether this common code should be in a WCF service called by all those sites.
Another option is to make your .Net code smart enough so that it can load the correct HTML front end based on the URL. That way you could deploy your code to one location, then have multiple virtual directories use the same code.
You could possibly try putting them in a common folder location and then change the assembly probing paths to look in that location.