I know this seems pretty basic, but I've been working with MVC for awhile and I'm not sure what works with asp.net.
Is it possible to organize code outside the App_Code directory or into separate projects? How would this be done?
Yes, it's possible.
You have a couple choices. One is to use Web Application Projects instead of Web Site projects. WAP's have a LOT more control over where code lives, compilation, etc.
Another is to create a Class Library project and reference this from your existing project. This is a great way to share code amongst multiple projects and/or solutions.
Incidentally, if you are wanting to stick with MVC, then I'd highly suggest you investigate Razor. I've heard nothing but good things about it. Personally, I'm not 100% sold on MVC; but the people I know who are love Razor.
To move code outside of the App_Code folder, you need to place it in a separate class library project, and the dll output from that project must registered in the GAC on your web server (and each of your development machines).
It's this last part that annoys me most, as it's not easy getting all the working with a source control system where the relevant revision that you need installed in the GAC on your local machine may change frequently.
Related
I'm working on an straight ASP.Net application. (no additional frameworks).
I've got several user controls (not custom controls) which I'd like to be able to package into a DLL for reuse/redistribution across several other applications. Ideally, we'd like to have everything self contained in (.ascx and source files) a DLL which could be added to the target project's references.
When embedding the user controls into .aspx pages, we'd like to be able see those controls in Visual Studio design view.
I've been looking around and seen several possible solutions for this.
Can anyone point me to a clear tutorial/example which will help step me through this process?
John, as far as I am aware, what you are asking is not possible, at least not out of the box with the .net Framework. When you build a UserControl in ASP .NET app and compile the solution, as you may have realized, the UserControl would be included in the dll of the project to which it belongs; it won't have a separate dll of its own. Since the UserControl won't have a dll of its own, you won't be able to make it available in the design view/toolbox.
For what you are asking, you might want to consider creating ServerControls instead. Server controls are harder to create than UserControl, if I recall correctly, you have to code it entirely, wont have designer available, but when you are done and compile, ServerControl will have it's own dll, which could be made available in CustomControls under Toolbox.
If you want a starting point for ServerControl, I would highly recommend watching the video from KudVenkat. His explanation and demos are second to none.
Link to the tutorial
Right now I have a single ASP.NET solution with one project in it. The problem I'm facing is that multiple developers are working on different parts of the project that are getting released at different times. Because of this my project manager is thinking we can split the project into multiple dlls instead of just one dll so that we can update just the modules that need to updated.
1. Is splitting the project into multiple projects (multiple dlls) the correct way to solve this problem?
2. If so, how do I do this?
Can I just copy the appropriate aspx/cs files to the new project, remove them from the old one and build? What about Master Pages, CSS, Javascript and User-Controls, will I need to copy those along as well or can they be referenced in the "Core" Project? Would I need to make some adjustments in IIS or can I just copy the aspx from the new "sub-project" to the root of the "Core" Project (essentially where the aspx files are now)?
3. If not, what is the better solution to fix my issue?
Thanks for your help
Edit (to add a bit more clarity):
Right now our structure is something like this (shortened and code-behind implied):
MasterPage.master
styles.css
SplashPage.aspx
Page.aspx
AnotherPage.aspx
a_MasterPage.master
a_Page.aspx
a_AnotherPage.aspx
b_Page.aspx
b_AnotherPage.aspx
b_AlsoAnotherPage.aspx
Can I take all the a_ pages and roll them into one project and all the b_ pages and roll them into another (which would separate the dlls).
If this doesn't make sense please ask and I'll try to explain it better
Yes
How? Don't think in terms of pages, but rather functionality. The best way to handle your issue is to move the business logic out of the ASP.NET experience layer project and put it in class libraries. You can then have different types of developers working on different types of code.
Now, if you truly have different "sites", meaning they serve different purposes, then you may have to move some pages to one and other pages to another. I can't answer whether that is a need or not.
Hopefully, this all makes sense. NOTE: If you code is contained in Page_Load() and event handlers, you are pretty much screwed until you can refactor the code into individual methods.
3.) What about some version control system, wouldn't that serve you better?
Splitting project like this isn't a good idea imo, it would make sense, if you would like to split logical/physical layers of that project (you could have different project for your data access, another for business logic etc.) But splitting to projects, where one contains "welcome.aspx" and second one "contact.aspx".. hmm I would rather use SVN / Git / TFS / Whatever ;)
Normally you split the project according to the function or feature eg. you could split off the data access layer into a different project.
I ussually try to keep my view together and separate the core features, so it would be easy to use the same dll's over different websites.
eg: I have a project with all the methods and a db for user management.
I could deploy this project on a server and reference it in all my websites.
This way users can use the same login over all my websites.
So once you have a core system, everyone can make his own project and just reference the projects needed.
Yes you just move your aspx/c# files to a different project and reference the new project in your existing project.
I do think that every project needs his own masterpage though (last time I checked that is).
I hope this answers you question.
In a website, I see some developers put code into app_code, and sometimes appcode (due to some bug), other files into DataModel, and other files into miscellaneous folders.
Is there a standard approach to organizing code within an application?
How is it different between an ASP.NET, MVC, Silverlight, Console, Database, and WCF application? The reason I mention WCF is because many people seem to have a shared types library that is linked between the server and client code.
Where can I learn these common practices without having to try, fail, and try again. I'd rather just learn it once from the experts.
the most standard well organized is MVC framework. For anything else, mostly i organize folders as namespace.
eg companyName.projectName.folderName
myCompany.StackOverFlow.Extension
myCompany.StackOverFlow.OpenID
There is no set in stone 'best practice' standard for organizing namespaces. My personal approach to keeping projects organized is to limit the content of any directory/namespace to about 20 items. This means I can fit the full contents of a folder into my screen, and also see every other item surrounding it (assuming other folders are collapsed).
On the other hand, lots of folders without much content can make navigation difficult as well.
Another thing you should do is to separate your solution into projects based on dependencies. For example if you are using m-v-vm, you should have a project for each of Model, View, and ViewModel.
Files placed in AppCode should only be files directly relevant to the presentation modules. Other files (ie ViewModel, Model, Controller etc depending on the framework you're using) would be preferably placed in separate projects.
Take a look at the "WCF the Manual Way…the Right Way" http://www.code-magazine.com/Article.aspx?quickid=0809101
We have two asp.net sites (based on episerver).
Using Telerik Asp.net controls.
We have some functionality that we want to have available in both sites.
Right now one of the sites use webparts/usercontrols and the other uses usercontrols.
Is there any way to share the functionality between these sites?
What I would like is to be able to share usercontrols between the sites.
Since your talking about user controls I'm assuming you also have .ascx files that are part of the user controls, which makes this tricky.
I guess the ideal solution would be to move everything into server controls, that way you could just reference the assembly, but if you are inheriting from other controls that utilize .ascx files, your kinda stuck with them.
One way of handling it is to use the file linking capabilities in Visual Studio (Add Existing File, click the down arrow, choose link option) to share the same physical file between projects within the same solution. This is not ideal simply because you have to make sure that the ascx files are copied to both sites prior to deployment (I've done it with a post-build script before), but there is a lot that can still be pretty fragile.
Another option that is more technically complex, but probably a "better" way of handling it would be to use a Virtual Path Provider to do the work for you. Here is an article which talks about using Virtual Path Providers to do the sort of thing you are wanting to do.
Start a new class library project, reference that project in both your site projects, then pull out the common controls and code into the library project.
Like mentioned you could put the files in a VPP directory in the live environment and that way only have to copy ASCX-files to one folder for a two-site-code-infront-update. Code-behind updates would need the DLL built and overwritten for both sites though.
If you are using SVN in your development environment you could also setup a svn:external linked folder from one of the projects and that way only have the code and it's revision history in one repository.
Scenario:
Let's say I have four very similar applications (i.e. most of the functionality is the same, but they are different enough to justify each being seperate applications).
What is the best way to re-use the common functionality code between them? COM+? Web services?
In general I'd typically just have the code in a seperate project (dll), but anytime that's updated, the file has to be updated for each ASP.Net application, and wasn't sure if there was a better way of going about it.
Thanks!
If possible, you can create a Visual Studio solution with a DLL Project and a number of Web Application or Website projects. The web projects would have a "project" type reference to the DLL project, and everything would build at the same time. Then you could use the "Publish" tool for each of your web projects as needed.
If all the apps are on the same virtual server, consider placing the shared assembly in the GAC. This allows you to diverge versions should the need arise, and keeps everything in the same place as a bonus. Downsides: this assembly runs with full trust and you should use policy and CAS to ensure there are no elevation of trust leverage points for external untrusted assemblies. You'll also need to learn about the [AllowPartiallyTrustedCallers] attribute.
As for the other choices, COM+, meh, a bit heavyweight. Good for transactional stuff. Web services, not so good for data heavy services, but if done right, can be fairly maintainable. The more it's shared, the better the pay off.
You can have your project, but instead of adding the common dll to the project reference add the common project to all solutions and then add a reference to the common project.
This way you can have one project on any number of solutions and you have your problem solved ;)