Where to save classes of the web-application - asp.net

I have to create a small asp.net-application. The last such web-application I have built was a while ago. At this time, I have saved my classes in the App_Code-folder.
During setting up the web-solution in VS2010, I have seen that VS does no more propose to create the app_code directory (right click on the project, Add asp.net-folder). Is the App_Code folder no more the prefered location to save classes of the web-application and where is the new place to store them?
Update
Thanks to Oded I have received the answer to my question.
If one has the same question as I had, probably he is also not aware (as I was), that there are two different types of projects with their own menu-points in VS: Web-Application and Web-Site. The organisation of these two types is different. For a web-application, the app_code-folder is not proposed in the asp.net-folder-menu . Maybe this information helps someone.

It is the preferred place, but VS 2010 just doesn't automatically create it for you any more.
As you can see from the documentation of app_code for .NET 4.0, it is still the best place for shared code.
In a Web site project, you can store source code in the App_Code folder, and it will be automatically compiled at run time. The resulting assembly is accessible to any other code in the Web application.

Related

Custom path for folder

How to add a reference to the App_code directory for a sub-folder in web project
I have been given a task to take an older, grown piecemeal over a decade internal website and bring it "up to speed". I have run into a problem in ASP files to "see" the app_code directory. Essentially the current site is a collection of folders that work(ish) that I am trying to collect together as a single project with the LEAST number of edits.
When functionality was superseded the old code was moved into a "deprecated" folder. The code files now reference object in the app_code directory which is not visible to the file from it's new location. The easy answer would be to copy a version of the class file into the "deprecated" folder but that seems more like a hack then a solution. The same for copying the App_code folder to a location visible to the ASP file.
My thought was to add a reference ("reference path") somehow to the deprecated folder pointing to the app_code folder but I cannot find how to do that.
A couple of other notes: 1) the site was built by using text editors and "freebie" editors - it has never been compiled or run in-total through VS before. 2) once I get it built and checked into TFS I am going to remove the deprecated folders. 3) I am working under some stipulations to satisfy concerns arising from actions of prior developers.
Code like:
tr.Controls.Add(GUI.GetTableCell("Salesman", 0, "Center"));
Works well when the ASP page is at the same directory level as the App_code folder ("GUI" is a class with a "GetTableCell" function).
If I can add a folder reference I can solve all of the remaining problems I have with this step in the project.
EDIT
Let me re-ask it this way. The image below is a composite of what I am facing in VS2017. I have such a feeling that a light bulb is simply not turning on for some reason. How I have done this so far is pulling down the current website from our internal Win2003 web server and am trying to convert it into a legit web project. I have done many of the steps necessary but there are 47 instances of the problem visible in the composite image from Visual studio
The code behind from SubscriptionEditor.aspx pictured lower right. Has reference to a namespace which is in the code files in the App_code folder (neatly hidden). This site functions fine but I am missing something to make it work from within VS. I am just at a loss.
For anyone that finds this I want to point out that there are a number of excellent answers available for similar questions here and i have looked at dozens and tried them all. The simple answer to my problem is "you can't".
How to convert ASP.NET website to ASP.NET web application came close
The problem being the source is just a collection of ASP files - it follows no project or template.
Namespaces are super important in development and the clever ways that prior developers found to breach that discipline can not be fixed through VS. It is simple a lot of bloody knuckle corrections of code and scope issues til the errors disappear.
The limitations put on me prohibit any solution. I will end up advocating not "saving the code" unless they are willing to put in the investment to heal the most egregious foibles. So if you see me in the "available for contract" sites then you know how that conversation went.

You have two ASP.NET projects. One contains a copy of the other's dll, and a reference to it. Can you run the projects on two different servers?

My question is about the necessary proximity of a dll to the project from which it was created. If you have two ASP.NET projects, and you copy the dll created by one of them, into the other project, (for example, putting it in a library folder), and then add a reference to that copy so it can be used, do the two projects need to run on the same server?
Many thanks!
Yes. You can definitely do this. You have to ensure that the referenced dll files are getting copied over. And as they are separate applications, you can easily deploy them on separate servers. Though I am not entirely sure why do you need to add a reference of ASP.NET project to another ASP.NET project. You might be able to achieve sharing of code by creating separate class library project and referring that.

c# asp.net Centralized UI Development

We have a lot of websites with common functionality developed by 3 persons, in the business logic we use a common library project (in a shared directory) so we all use the same functions. This way the corrections and improvements are shared for the following projects or when we recompile an existing project. We have a class for some UI common functions too (loading a ListControl with x data and so)
The problem is with some web parts like CSS, Javascripts, Common Pages (login, configuration, customer management), those we don't know exactly how we can centralize them so we have those parts in the shared project so we don't have to copy paste corrections/improvements manually to the other websites each time...
Example of current website structure:
-MyWebSite1
-Styles.css
-Scripts.js
-Login.aspx
-Funx.cs (Functions specific to this site)
-Consx.cs (Session and other variables specific to this site)
-CommonProject (In a network shared directory)
-FunBusiness.cs
-FunWebUI.cs
-ConsBusiness.cs
-ConsWEB.cs
Is there a way of doing this?
For now the closest we have come to solving this problem is following this article for the Javascript part:
http://msdn.microsoft.com/en-us/library/bb398930(v=vs.100).aspx
We are now investigating using only one reference to a js file and including the other javascript references dinamically and the common CSS and MasterPages parts...
Maybe you can add those common references files as Linked File in Visual Studio. In this way you can maintain one file, while kept in a different location.
From Microsoft:
Link file leaves the file in its current location and maintains a link to the file from your current project.
Another solution would be to create a copy script before compile in Visual Studio. Reference over here.

ASP.net: Can I have 2 different versions of same dll/assembly in the bin folder?

I am working on a large web application implemented in ASP.net. The main part of application, much of it implemented by a 3rd party, is managed by others so I don't have much control over it.
I have implemented 8 ASP.net custom controls which compile to separate DLLs and are put into the application's bin folder. These controls have to link to a couple of DLLs (or should that be assemblies?) from the main application which are also stored in the bin folder. Let's call them MainAppCore1.dll and MainAppCore2.dll. These seem to be managed .NET code.
My problem is that the main application has been updated, and worse looks like regularly being updated in the near future, due to to bugs problems I have compiled all my controls against the original version of the main app dlls, so now they won't load. Obviously I can solve the issue by recompiling all the controls against the new versions of MainAppCore1.dll and MainAppCore2.dll but am looking for a smarter way
My question is: is it possible to keep 2 versions of the main app dlls in the bin folder so that my controls will keep working (probably) each time the main app is upgraded?
I don't want to have to edit the web.config file by the way as this would be politically complicated.
Shortly and Simply, you cannot . Broadly speaking having two versions of .net assemblies in a single folder is only possible in GAC(Global Assembly Cache) folder which is a special folder, where multiple versions of .Net assemblies can run and your control assemblies can point to specific version in GAC, regardless of how many versions exist in there. One possible solution is to ask your 3rd party vendors to strongly name their MainCore1.dll and install it in GAC, every time the version changes, and then in your web.config you can point to a particular version.
Place your 8 custom controls in their own library project and reference that project from the main one. Presumably everything is in source control so there shouldn't be any versioning problems when you do a "Get latest".

Separating Web Applications into multiple projects

I have a web application that is becoming rather large. I want to separate it into smaller more logical projects, but the smaller projects are still going to need to access some of the classes in the app_code of the main project. What are some good methods to accomplish this?
Add a class library project with the common classes and add a reference to this project to each of the new projects.
So you'll have the following Solution layout
/webapp1
/default.aspx
/....
/webapp2
/default.aspx
/....
/lib
/Utils.cs
If you are only looking for a way to organize your files, then you can create a folder for each sub-project. This way you'll be able to get to the content of app_code and maintain a level of separation with very little rework.
If you are looking for the best way to do this, then refactoring your code to have a common Class Library based on what is reusable in the app_code folder and multiple, separate projects that reference that library is the way to go.
You may run into problem refactoring the code this way, including not being able to reference profile or user information directly. You are now going from the Web Site to Web Application paradigm.
http://www.codersbarn.com/post/2008/06/ASPNET-Web-Site-versus-Web-Application-Project.aspx
Extract your common code from app_code into a class library which is referenced by each of your other projects.
I like the 3 Tier approach of creating a data access project, a separate business project, then use your existing site code as the presentation layer, all within the same solution file.
You do this, like posters before me said, by creating Class Library projects within your existing solution and moving your App_Code classes to the appropriate layer and then referencing the data access project in the business project, and the business project in the web project.
It will take a bit of time to move it all around and get the bits and pieces reconnected once you move so make sure you set aside plenty of time for testing and refactoring.
In CVS & Subversion, you can setup what I think are referred to as "aliases" (or maybe it's "modules"). Anyway, you can use them to checkout part(s) of your source control tree. For example, you could create an alias called "views" that checks out all your HTML, javascript, and css, but none of your php/java/.NET.
Here's an example of what I'm doing within my projects.
The basic idea is to have all common files separately from htdocs so they are not accessible by client directly and sharable.
Directory structure:
public_html
The only htdocs dir for all projects.
Stores only files which should be directly accessible by client, ie js, css, images, index script
core
Core classes/functions required by application and other scripts. Framework in other words.
application
Stores files used to generate separate pages requested by public_html/index script + classes common to all projects
config
Configuration for all projects, separated by project
templates
Template files separated from all other files
The public_html/index script is then used for all projects on all domains/subdomains and based on the requested URL loads proper pages...
A somewhat simple approach is to group the code in your app_code folder into it's own assembly. The only issue that you could possibly run into is if the code in your app_code folder is not decoupled from the elements on you pages (This is normally always a bad idea since it indicates poor cohesion in you classes).
Once you have your code in a separate assembly you can deploy it to any number of servers when you are upgrading you apps.

Resources