I want to divide business layer (BLL) of an asp.net application into multiple components. Each component is a .NET class library which is compiled as a standalone DLL. These components should have their own configuration files. For example "MyNameSpace.Users.dll" contains classes about users of the website and there's a password policy to check if password length is at least x characters. When webmaster edits the config file of this DLL and set x to y then component (DLL) should use new value (y) in the future and enforce passwords to be at least y characters. I want each component as a single project and compile them separaely (and not to put all projects in a solution in Visual Studio), and put the DLLs of these libraries into the "Bin" folder of my ASP.NET application.
Is it possible ?
Where should I put these config files ?
Managed Extensibility Framework (MEF) released in .NET 4.0
http://mef.codeplex.com
imho It's possible but not out of the box.
ASP.NET uses by defautl only the one web.config in the web root (and pproriate machine .config files higher up in the hierarchy). But you can create custom settings providers for each of your dlls that read values from separate .config files.
see http://msdn.microsoft.com/en-us/library/ms228060.aspx
This way you create different SettingsManager providing settings to parts of the App and reading the info from files.
Plus you can use FilesystemWatcher to reload values when the additional .configs are edited.
Related
Is there a configuration provider already pre-configured in .net core that I can just use without having to add in boilerplate code? In the same way that app.config files just work in full .net.
I'm writing a console app in .net core 2 and it needs some settings, a connection string and a few app settings that I would have previously just tossed into the app.config file.
I've started googling about configuration in .net core and found a whole heap of documentation about how flexible it is - you just add a file, make sure it gets copied to the correct location and then spin up a configuration builder add it the correct provider build it etc. etc.
As nice and flexible as it is I don't want to clutter up my tiny console apps with this config boilerplate - it feels like we have to roll our own config for each app.
Ideally, in a .NET Core application, one would choose JSON setting files over XML configuration files, but it is still possible to use legacy XML configuration files if needed.
There is an API to access application setting files; just check out the following NuGet packages: Microsoft.Extensions.Configuration and Microsoft.Extensions.Configuration.Xml, and this article might be a good reading: http://benfoster.io/blog/net-core-configuration-legacy-projects since it also covers the integration of app.config or web.config files, as well as how to create a custom configuration provider.
I need a Solution with one main .Net Core Web Application and areas to be created, but each areas has to be a .Net Core Web Application. The reason I need this is, the projects in the area needs to have separate dll and other supporting files in the bin of Main project.
Is that possible in .Net Core ?
If so, I have tried to imply the same, but each project is created with a Main method in Program.cs, which fails my build stating "Multiple entry points in my solution".
Sounds like you need Features. This will let you group and separate your Areas into different folders and then move these into different shared projects or portable libraries. You can then reference and use these in your Main .NET Core Web App.
These are not standalone Web Applications as you asked for, but it's the best way i can think of, in order to separate the different components in your application.
There can only be one entry point in a C# program.
If you have more than one class that has a Main method, you must compile your program with the /main compiler option to specify which Main method to use as the entry point. For more information, see /main (C# Compiler Options).
I have added a resource file in App_GlobalResources called FileList.resx.
Now I access the contents within the code by using
My.Resources.FileList.astro1 etc.
It works fine if I set the Build Action of resource file to Embedded. However in this case the resource file is not available after compile and I can't change it later.
If I set the Build Action to Content I get an error : Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "WAP.FileList.resources" was correctly embedded or linked into assembly "WAP" at compile time, or that all the satellite assemblies required are loadable and fully signed.
Please advice me.
Are you using a Visual Studio Web Application? Or a Web Site?
In the latter case, you should be able to change the Resource file after deploying the site, and it should get automatically recompiled on the server. In the former case, it's a built-in that can't be changed after the site is compiled before deployment.
If that's a problem for you, there are of course alternatives to Resource files....
In any way of compiling and deploying your application all resource files will compiled in related to each resource file assemblies. In all cases, resource assemblies are ultimately created for each directory in the site, and satellite assemblies are generated beneath their respective culture-specific directories. Even when the site is JIT-compiled, the outcome is equivalent.
So, you must use Build Action of resource file to Embedded, but as possible solution for dynamic resource definition you can place you resources in a database. And even provide a Resource provider. In that case your database solution would have all the benefits that suggested by resource management aka dynamic culture definition, using resource binding to control, etc.
Here you can find some tutorials how to implement Resource-Provider Model in your application:
Extending the ASP.NET 2.0 Resource-Provider Model
Creating a Data Driven ASP.NET Localization
Resource Provider and Editor
I'd like to understand if what I have in my mind is a "good practice" and if so, how I can get it.
First of all let's say that we are using VS 2010 and the .Net 4.0.
In our solution we have one ASP.NET WEB Application and other Class Library projects, where some of them are referenced in the WEB Application project.
For the WEB Application we've implemented the "Web.config Transformation" since we manage the deploying on three different environments (Test, UAT, and Production).
The point is this, as I said we have projects referenced in the WEB App. and some of them access to the database, so the question is this: is there a chance to let the WEB.config transformation process to impact on those projects in terms of the connection string? Basically before we deploy, once we select the environment (i.e Test), we'd like that choice will affect to the app.config files of the referenced projects.
If you reference library projects from a web project you configure them only with the web.config. You have to merge the config sections of the web and the library project to the web.config. After this you can use the config transformations to replace sections, connection strings, whatever of all parts of your project.
Here is a short description how to merge the config sections:
web.config and app.config confusion
In SharePoint, one can create a Solution Package, which includes features, list and site templates etc, then after adding and deploying the solution, application's dll's and files are deployed to each web front end (basically, the SP Timer service in each WFE runs the deployment jobs.) Then, as SP features are activated (once per farm), web.config can be modified, etc.
Is there anything similar to deploy ASP.Net web applications? By deploy, I mean to install and make everything needed for a web app to work (web.config changes, apppool creation/update/deletion, dll GACing, etc). Or custom automation scripts are the only alternative?
Thanks.
I've never used one, but you could check out Web Deployment Projects.
The core feature list is here, and the enhancements from 2008 are here.
A Web Deployment project provides the
following features for building and
deploying ASP.NET 2.0 Web sites:
ASP.NET 2.0 precompilation as part of the build process.
More flexible options for generating compiled assemblies from a Web
project, including these alternatives:
o A single assembly for the entire Web site.
o One assembly per content folder.
o A single assembly for all UI components.
o An assembly for each compiled file in the Web site.
Assembly signing options.
The ability to define custom pre-build and post-build actions.
The ability to exclude folders from the build.
The ability to modify settings in the Web.config file, such as the
element, based on
the Visual Studio build configuration.
Support for creating .msi files with setup projects.