I'm working on a web site project. I have inherited a C# class file that I would like to put in a DLL, but the class references classes that reside in the App_Code folder. Is is possible to access App_Code classes from a DLL?
Thanks
ASP.NET websites - as opposed to ASP.NET web projects - are compiled when executed. So when you build them you won't see a .dll output in a bin folder that you could reference from anywhere.
But it wouldn't make sense to use a website as class library anyway. If it contains classes that you need, it would make sense to pull them out of the webiste. That means
create a new class library project
move the class files from the website into the new project
make whatever adjustments are needed to for it to compile.
How well this works may depend on how tightly the code is coupled with the website project in which it lives. For example, a class might look for values in HttpContext.Current. If that's the case, the class won't work outside of a website as-is. You'd need to modify it to get inputs differently. (Without seeing the code, it's hard to know whether this will be trivially easy or tedious and frustrating.)
Hopefully if the classes aren't too coupled to the ASP.NET environment you can remove them from your existing website and even that website can use your new class library.
Related
I've read in other posts that you can put the business logic in a VS2013 MVC project "anywhere", which I take to mean "possibly outside the Controllers folder".
However, when I create an App_Code folder in my project, and put business logic classes in it, (with the build property set to Compile, not Content) I get a compilation error, on the following, and the code editor intellisense won't recognize the the .Caching in the following:
using System.Runtime.Caching;
If I move the class back into a subfolder of Controllers, no problem, the .Caching appears in intellisense and no compilation error occurs.
Any explanations of why this might be so, and how I might adjust my project to allow business logic classes to operate correctly outside the Controllers folder, would be appreciated.
The App_Code folder contains code that is compiled at runtime.
See the following reference: http://msdn.microsoft.com/en-us/library/t990ks23.aspx
If you have business logic, it's probably best to put it into an external (from the webiste) library to increase reuse and enable better compartmentalization.
Add a business layer class library project to your solution, and then add reference to this business layer class library project to your MVC project.
First off, there's no such ting as App_Code folder for MVC.
Why?
Well, the App_Code concept is meant to work with Website Projects, however, MVC are Web Application Projects which is a framework or implementation of a pattern to work closer to the HTTP protocol and web requests and separate concerns into presentation (views), request handlers (controllers) and models. So, don't expect it to work with App_Code
Suggestion
Create/Add a Class Library project in the same VS Solution where you can keep all your business logic and then reference this project in your MVC app
I have a project which was done in a website. moving to a web app will be a real pain.
It does get published, and thats how it gets moved to production.
as a result of the publishing, all the classes inside the app_code folder get compiled into an app_code.dll file.
I want to import this dll into another project.
it imports fine. but when i try to deckare an object from inside, my new project cant get a reference to the object.
Can this be done?
Just don't do it. Create a class library project and encapsulate the functionality into a named dynamic link library, which is the output, that can be shared and versioned properly (as opposed to its history being mixed with the nature the website that uses it) in its own right.
There are a lot of variables and methods in my program and I want to seperate some of them in other class files. But as the program grows the methods and functions can change.
I searched on the net but many people generally speaking for dll files. Without making a dll file, how can I arrange my code and split into small class files?
Yes, just split it out in to a separate file in a new class but still inside the same project. The term for what you are doing is called Code Refactoring. There are some tools built in to Visual Studio to make it easier to do, and there are some 3rd party tools that add even more features to make it easier to do.
But all it boils down to is just making new classes in the same project and referencing those new classes from where you took the code out from.
You can add folders to your solution. Classes are by default a namespaceprovider, so that classes in this folder have a different namespace.
For example if your default-namespace is MyNameSpace and you create a folder called Entity then all classes in this folder have the namespace MyNameSpace.Entity
And all Items in a project are compiled to one single dll or exe
Just add more classes to the project and put the data and behavior (methods) into the appropriate classes. The project will still build into a single exe or dll.
Generally, it's better to add a second project under the same solution call it "CommonLib" or something like that. Then you add it as a reference to the main application and set up the project so that the applications build depends on the libraries build. Add a using statement for the common lib where ever you want to use those objects. This is definitely better for large scale or enterprise applications. There's a pretty decent chance that somewhere down the line you'll want to reuse some of this code, if everything builds into a single exe that won't be an option.
hopefully this is a quick one. If I have c# class files on WebsiteA.com - can I reference them in WebsiteB.com? Both sites are on the same server, so I was hoping to reference them on a static address? (d:/inetpub/wwwroot/websiteA-com/app_code/MyClass.cs)
Is this possible? Or - do I have to copy the class file to WebsiteB.com and simply use that?
I just want to avoid repetition when I need to make any changes - avoiding changing both sites.
I've built both sites in .net 4 using visual studio 2010 express.
Thanks
If I were you, I would take all the classes needed by both websites and create a Class Library Project (DLL). Then reference that project in each website and use the classes. This means each site will be deployed with the same DLL but you will have a single project for common classes.
Hope this helps (I know it's not strictly the answer)
Sure you can.
I don't think that adding the class from the app pool of the IIS folder is a good idea though.
I believe it's a better practice though to make a class library as a separate project called for example Shared and reference it in both projects.
in Visual Studio you can "Add existing" then choose the "Link" option to add source code from another project
this can be much easier to manage than a shared class library - you can even include the same code in wildly different projects (compact framework, different versions of dot net, etc.)
Honestly, I can't word my question any better without describing it.
I have a base project (with all its glory, dlls, resources etc) which is a CMS.
I need to use this project as a base for othe custom bake projects.
This base project is to be maintained and updated among all custom bake projects.
I use subversion (Collabnet and Tortise SVN)
I have two questions:
1 - Can I use subversion to share the base project among other projects
What I mean here is can I "Checkout" the base project into another "Checked Out" project and have both update and commit seperatley. So, to paint a picture, let's say I am working on a custom project and I modify the core/base prject in some way (which I know will suit the others) can I then commit those changes and upon doing so when I update the base project in the other "Checked out" resources will it pull the changes? In short, I would like not to have to manually deploy updated core files whenever I make changes into each seperate project.
2 - If I create a custom file (let's say an webcontrol or aspx page etc) can I have it compile seperatley from the base project
Another tricky one to explain. When I publish my web application it creates DLLs based on the namespaces of projects attached to it. So I may have a number of DLLs including the "Website's" namespace DLL, which could simply be website. I want to be able to make a seperate, custom, control which does not compile into those DLLs as the custom files should not rely on those DLLS to run. Is it as simple to set a seperate namespace for those files like CustomFiles.ProjectName for example?
Think of the whole idea as adding modules to the .NET project, I don't want the module's code in any of the core DLLs but I do need for module to be able to access the core dlls.
(There is no need for the core project to access the module code as it should be one way only in theory, though I reckon it woould not be possible anyway without using JSON/SOAP or something like that, maybe I am wrong.)
I want to create a pluggable environment much like that of Joomla/Wordpress as since PHP generally doesn't have to be compiled first I see this is the reason why all this is possible/easy. The idea is to allow pluggable themes, modules etc etc.
(I haven't tried simply adding .NET themes after compile/publish but I am assuming this is possible anyway? OR does the compiler need to reference items in the files?)
UPDATE (16/05/2010):
I posted a similar question with a little more detail for question 2 on Experts-Exchange. I don't want to post all that info here as it just will be too messy but it explains question 2 in greater detail.
For your first question, you want to use svn externals. More details can be found here: http://svnbook.red-bean.com/en/1.0/ch07s03.html
For your second question, you need to create a seperate assembly and the easiest way is to create a new project within your solution. You can't have a single project emit 2 dll's (that I know of)
For your first question:
If the base project is a library then there is nothing stopping you from creating the following directory structure on your SVN:
Base project
Cool project nr 1
Cool project nr 2
All projects built on the Base project will include a relative reference and then everybody can checkout his Cool project X and the Base project and work on them. Checking-in changes for Base project will allow everybody else to see them by updating their Base project image. Advantage: only one SVN trunk required.
For your second question :
I tried my best, but I can't understand what you're asking :).