Here’s the situation: I am writing an ASP.NET MVC application. I want to use EWL’s data layer, and I want to use EWL system manager (formally RSIS) to deploy the application. But, after the number of problems I’ve found, I’m losing motivation.
Web.config stomping @greg_smalter has said that its known that EWF and MVC can thrive happily together. I’m not convinced. I’m using the latest MVC. But EWL’s stomping the web.config completely breaks it. I revert it locally which makes everything happy again. But EWL system manager regenerates dependent logic when it builds, stomping the web.config on the build server, so when it’s deployed it’s broken again. I could get around the stomping if I didn’t want system manager.
Ewf folder
I don’t really care, but it’s extra and not-needed. But I do think extra-things-that-don’t-need-to-be-there will bother other developers trying EWL for the first time.
CSS HTTP handler
I’m not hooking Global into EwfApp because I don’t want the error handling. But, it’s required for the CSS HTTP handler, which I also do not want.
Error Handling
I want full control over how my errors are handled. This is the same issue as the discussion we’ve had in meetings and via email. The main example from those conversations being, we’re writing a web service that must return parsable json for the client, always. However it’s impossible to escape EWL’s error handler if the exception reaches the application error handler. Attempting to do anything in Application_Error is futile: the exception was already cleared.
Okay Sam but it’s absolutely possible to use EWL’s data layer without signing up with all of these things. All you have to do is initialize the application as if it’s a console application
Yes, but not to use EWL system manager. EWL system manager won’t include your project in the logic package unless it’s defined in Development.xml. But, defining your project signs it up for all of this magic.
Possible solutions
Here are the ways my problems could be resolved.
Allow configuring a web project for inclusion in system manager’s logic package but don’t also sign it up for the rest.
Break-out EWL’s data layer into a completely separate package. (Actually, this wouldn’t solve my problem because the web.config would still get stomped on the build server.)
Manually sign-up or opt-out of all magic features, including but not limited to: CSS generation and handling, Error handling, EWF.
A massive benefit of opt-in/opt-out features is that it lessens the burden for others trying out EWL. Developers want control over their projects. When it comes down to “use features that make life easier, but lose all control” and “have full control, but development is slightly more difficult”, they’re going to choose the latter. I firmly believe in guiding the developer in the right direction, but forcing a path is like building a glass tunnel at a national park. I would rather have the ropes that say “do not cross.”
Ok. If you were using EWF and wanted to add Web API or MVC, as I have, I think you’d be fine. If you are using MVC and want to use one feature of EWL, then yes, I could see it generating a web.config way different than the stock one.
You get away with it because you don’t have a build server saying “No really, you’re going to use this web.config and not whatever you think you were doing.”
EWL stomping the web.config is annoying besides the issues in this post. For example, you can’t use NewRelic (a service that is becoming super-popular) to monitor your ASP.NET application, because you need to add some stuff to the web.config, which EWL takes out. And it would just be silly of us to add features to EWL that wind-up generating what you want put into the web.config. We’re too intrusive. We broke that very-pink web application we work on together several times this past year because an EWL-stomped web.config was checked in.
EWL should certainly not block you from using MVC in an EWF web app. But we need to be careful to not give developers too much flexibility since that would go against one of EWL’s main goals; see http://www.enterpriseweblibrary.org/.
My responses to your specific points:
CSS constant class generation: I just approved your fix for this, so there’s no longer an issue.
CSS HTTP handler: The only intrusive thing about this is how it blocks any CSS request that doesn’t include the correct timestamp in the URL. I’m open to relaxing this constraint if it’s a big problem. But the purpose was to prevent stale CSS from ever getting used after a deployment, and I think we should look into how MVC solves this problem.
Error handling: I’m currently working on making this compatible with Web API. When I’m done, throwing HttpResponseException or whatever you do when you want to send the exception to the client should work fine.
Ewf folder: I don’t think this is a big deal at all. Also, we can eliminate it when we’re completely separated from Web Forms.
Web.config stomping: This is the big one. Letting developers completely opt-out of Web.config generation would open them up to all kinds of nasty errors, and I don’t know if there is any middle ground between that and full generation besides offering some limited flexibility via the EWL config files. But the good news is that I don’t see anything important in that MVC config file you posted besides some of the appSettings keys and maybe the pages/namespaces section. I’m open to automatically including all of that in the generated Web.config file if you agree.
@samrueby, can you give me a few examples of what you’d like to put in appSettings besides the MVC presets? Remember that for your own settings, you can always just create fields in GlobalLogic or anywhere else. And if you need per-installation settings, EWL makes it easy to have custom per-installation XML config files.
We want to make EWL as easy as possible for developers to get started. The thing with appSettings is that it allows for completely arbitrary settings values. The possibilities are endless. That is where many 3rd party libraries and software look for configuration values (that’s exactly why we want to put values there). I’m not worried about my own configuration. appSettings is standard and that’s where other tools are going to say values need to be to configure their stuff.
Just realized avoiding stomping on appSettings won’t be enough to fix the reason we have to constantly revert web.config in one Fusion system because the property being stomped is machineKey.
What if, before we generate the Web.config file, we look for an existing file and try to pick specific things out of it that we can incorporate into the newly-generated file? We could grab appSettings and machineKey to start.
