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.
Related
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
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.
I have one dll containing my entire mvc app running on iis7 server. Should I instead have compiled controllers and business logic into separate dll's? Furthermore, should I install the non controller dll's in a separate server and if so do I configure a new virtual directory to the remote server?
What is the typical practice here? Thanks
I guess that depends on your business needs, but in general I am a fan of modularity. We have our Model shared between multiple sites so it is in its own DLL and the controllers etc. for each site are generally in another (for each site) and additional add-ons in their own as well.
Compiling into one DLL would probably get you a performance increase, but you would be hurt when it comes to upgrading individual modules.
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.
I'm working on building a set of ASP.NET (2.0) web-services to be deployed into a single web application under IIS7. The services will be added incrementally (over a period of a year or more) by multiple programmers. How should I organize my source in VS2005.
Should I use one project or several?
Should I use a Web-Application or Web-Site project.
How do I manage the web.config that they will all share.
Thanks for your advice.
Do you use source control now? All of your "control" problems are solved by any decent source control system (i.e., not VSS).
I'd put them into a single project assuming they have code and types in common between them. For instance, if they use the same data access layer and underlying database.
I would never use web site "projects" for web services. Any of their advantages are advantages for web sites made up of web pages, and not for the more complex requirements of web services.
I'll speak to how our shop handles this, which I find to work well.
We use several projects. One for each web service. This allows us to publish one service without effecting the others. We're also on VSS (bleck!) which makes for less conflicts.
We use a Web-Site project and it works fine
We manage the web.config by doing a diff on the file before we publish. The web.config's are something that rarely change