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
Related
We are updating an ASP.NET Web Site project that uses ADFS 2.0 Authentication to use the one click "Publish Web Site" deployment process. We currently have three different FederationMetadata.xml files for each environment (dev, test, prod). How do we publish these files to each environment?
We use the web config transformation files for the web.config file. But I do not believe this can be used for xml files? From the searches that I have done I found two possible responses to this, neither seem very good. First one says to delete the FederationMetadata file and manually configure ADFS 2.0 (How do I change my WCF's FederationMetadata.xml file for various deployments?). We could do this but it seems like a step backwards. The second involves creating a dummy FederationMetadata file and populating it in the global.asax.cs file. (How to deploy asp.net web application to development team via TFS when setting up ADFS authentication). This approach seems very hackish and hardly the recommended approach.
Is there a recommended approach for this? Is there something obvious that I am not seeing? Any thoughts on this would be much appreciated!
If you indeed did manage to get the web.config correct then you can generate the metadata on the fly (per request). Same code for all environments. No need for the static file.
In telegram style just for the class names: For a Forms ASP.NET application it would be an HttpHandler (for MVC a controller). In the handler you must build a ApplicationServiceDescriptor, and use a MetadataSerializer to spit out the XML. Fill it with the info from FederatedAuthentication.WSFederationAuthenticationModule (which has obtained it from web.config).
I have three different websites that uses some base classes, usercontrols. And my questions here is that it possible to share these resources between this sites from single physical location? And also want to use single web.config for all three sites. As this will give me much more ease on maintenance issues.
So, if the above scenario is possible than how to achieve it.
You can share the resouce between the website by Creating DLL of your project and put that DLL in GAC
The Global Assembly Cache or GAC is a machine-wide .NET assemblies cache for Microsoft's CLR platform. The approach of having a specially controlled central repository addresses the shared library concept and helps to avoid pitfalls of other solutions that lead to drawbacks like DLL hell.
Deatils about GAC on WIKI
For Configuration Data
as per the concepts Web.Config file is private for each web site if you want to share the configuration data than make use of machine.Config file which is having data common for all website running on the machine
You could use the probing path config setting to define a location for each app where they can find the shared assemblies. That would mean you wouldn't need to strongly name the assemblies & store them in the GAC (although that is probably the best approach)
If you want to share config across the apps, you'll probably need to create some alternate config system. as #pranay said a web.config is private to the app. if the 3 apps are on the same server & share a common root (eg /apps/app1, /apps/app2, /apps/app3) you can put the config in the parent config.
Q:
Recently , i face some problems, i have a dll common among a lot of applications,and any change to this dll require to build it, copy and paste it in each bin folder of these applications ,and add the new reference so i decided to convert this dll to a web service in stead to overcome this overload..
I make a web service application contains set of web services(mapping to each class).
I face some problems here:
In the original dll, there are
classes use methods exist in other
classes in the same dll, and i face problems when i
tried to use web service methods in
other web service class.how to fix
this problem.
In the original dll there are set of
static classes with static
methods.how to make the equivalent in
my web service application.
Any overload method cause a problem
in my web service.
When using Dictionary<string, string>
as a parameter in my method.
Note:the original dll contains the connections to the data base. Is converting it to web service is the optimum solution?which one is faster in my case a web service or the dll?Should i tend to WCF instead of?
thanks in advance.
In my applications I usually have all related projects in the same solution. But when I need to use projects across applications I replace the project for a dll reference.
Because I use Subversion I solve the problem of copying the dll by adding an external property do my libs folder, referencing the build of the dll.
If the external dll is updated very often than you probably need a continuous integration system to handle that for you.
I usually add project reference and keep all my projects under single solution, so I do not have file copy issue. You might be missing project reference, instead you could have used assembly reference. Verify that first.
First advice, don't create a web service if you don't know what it is and how it can be used. People tend to think everything is a web service since creating a web service in WCF is so easy by using visual studio tools. Since you ask like converting DLL to a web service, I assume that you are beginning with learning web service.
All you need is kind of continues integration system otherwise a simple build system which does the build for you and it copies the files wherever depended applications folder. Hence you can save your time for coping files manually. When you do this, you will not have any of those 4 problems you have mentioned.
If you are lazy enough to learn the build system, simply write a batch file that would copy the files for you. I do have batch files which does xcopy files.
What way makes the most sense? I have a ASP.NET app... and maybe a Silverlight app in the future.. I want both to talk to web services..
At first, I like have the WCF project be by it self for the seperation..
But then I thought.. What is the point since I can just as easily have a 'WEBSERVICES' folder that contains all the .svc files and code in the EXISTING website project. ... Atleast that way.. deploying to a remote host will be a little easier since everything is in one project..
any other considerations ?
Why not have:
your WCF service and data contracts in a Contracts assembly
your WCF service implementations in a Services assembly
reference those two assemblies from your web site or web app
put the *.svc files into a WebServices directory
That way, you have
clean and nicely organized separation of concerns
the deployment files (*.svc) are in your web site / web app as you want
you can still extend / use your WCF code in other ways (e.g. self-hosting) later on without much fuss
Two things to consider:
Security - are your services only going to be used by your application, or do they have the potential to be used anywhere else (after all they are services). If so, you will be granting access to your application in order to grant access to your web services, or at least tweaking the access to that specific folder, which might lead to security breaches.
Deployment - If you do changes on your service that doesn't break the contract, in order to deploy the changes you will have to deploy the whole application.
I would prefer to go with the approach that Marc suggested (e.g. have an assembly for contracts, one for the service implementation) and have the webservice hosted as its own application and reference it from the ASP.NET app. This way, you have proper separation of concerns and can maintain both separately.
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.