How can I put the LINQ to SQL generated classes in a dedicated DAL project so that I can access it from various other projects in the same solution? I.e. so I can use one for Web, and one for Windows Forms?
Absolutely no problem - just create a "class library" project and create your DBML file (LINQ-to-SQL file) in there.
Now, from all your projects that need this particular Linq-to-SQL file, add a reference to that class library assembly, and use the classes - and you're done!
The Linq-to-SQL DBMX file and its associated classes are just pure C# business objects and methods - there's nothing web- or Winforms-specific about those - you can use those in Winforms, WPF, Web Forms, ASP.NET MVC - you name it.
Marc
Related
Visual Studio 2015 + all updates.
Asp .Net Web application (MVC).
I start off by adding a few class libraries and separating the Asp .Net WA into layers i.e. DataAccess, Business Logic and the web project itself.
Once separated I add relevant references and everything is working as I expect it to be (i.e. the application functions as it did before I separated it into layers).
In my BL (Controllers are found here). I don't have the option to Add a Controller, like you would when right clicking the Controllers folder in the default project, so add the below line
<ProjectTypeGuids>{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>
to the csproj file for my class library and the Add Controller option now appears. Create a controller but throws an error which was due to not having a web.config file - add this file and all works (although it would be nice to have this library working without a web.config file).
The problem I've hit is, when the Controller is created it also adds a View template within the class library but my Views folder is located in my web project.
Have I done this wrong? Is there a workaround so when a controller is created, it also creates the Views into the correct project? Or another approach for this?
This is just a guess, but it seems like you are try to use a UI-based architectural pattern to build your business layer.
Typically, your models, views, and controllers are all maintained in the main web-app project. Any supporting functions (like your BL and DL) are added via class libraries. The Visual Studio MVC templates are built around that concept, which is why you had to manually add support with the GUID - and why it automatically creates the view.
If I may ask, why are you trying to build controllers into your BL? If you are trying to decouple your UI from your server code, perhaps WebAPI would be a better option.
UPDATE - A few helpful links
ProDinner - ASP.NET MVC Sample App
N Layered App with Entity Framework, Autofac, ASP.NET MVC and Unit Testing
Architecture Guide: ASP.NET MVC Framework + N-tier + Entity Framework and Many More
Most of your issues boil down to using the scaffold. The scaffold is great when you're just starting out or for extremely simple projects, but it quickly falls down beyond that. Specifically, adding a controller via scaffold is designed for an MVC project, so it expects to find things you'd find in an MVC project. Additionally, it creates scaffolded views in an appropriate directory in Views because, again, that's what it's designed to do.
The simplest solution, then, is to just not use the scaffolds. A controller is just a class that inherits from Controller. Nothing special there. Then, you can create the views where you want to create them.
I have several websites and these website share several components. It was quite easy with classic ASP.NET WebControls ascx. I created several such controls, put into one dll library and I reference these libraries from these websites via namespace.elements runat=server...
But I don't know how to do it after I have upgraded to ASP.NET MVC. I can put model and cotroller class into dll.
But how should I put and reuse Views into dll?
I suppose that Views are not compiled into dll, if I can change the View without recompiling the dll.
EDITS:
I would prefer some standard solution over third party. The last solution for me is to use StringBuilder instead of ViewEngine.
I've been using Razor Generator for several years to store reusable MVC views and helpers in separate .dll.
Razor Generator "is a Custom Tool for Visual Studio that allows processing Razor files at design time instead of runtime, allowing them to be built into an assembly for simpler reuse and distribution."
Installation instructions
It’s on the VS extension gallery, so install
it from there. It’s called “Razor Generator” (not to be confused with
“Razor Single File Generator for MVC”).
It is quite simple to use:
Usage in an MVC app
Install the 'RazorGenerator.Mvc' package, which registers a special
view engine
Go to an MVC Razor view's property and set the Custom tool to RazorGenerator
Optionally specify a value for Custom Tool Namespace to specify a namespace for the generated file. The project namespace is used by
default.
Optionally specify one of the generators in the first line of your Razor file. A generator declaration line looks like this: #*
Generator: MvcHelper *# . If you don't specify this, a generator is
picked based on convention (e.g. files under Views are treated as
MvcViews)
You'll see a generated .cs file under the .cshtml file, which will be used at runtime instead of the .cshtml file
You can also go to the nuget Package Manager Console and run 'Enable-RazorGenerator' to enable the Custom Tool on all the views.
And to cause all the views to be regenerated, go to the nuget Package Manager Console and run 'Redo-RazorGenerator'. This is
useful when you update the generator package and it needs to
generate different code.
MVC project should be chosen for class library in order to support intellisense and other useful features.
Usage in a View Library
If you need to create a separate library for your precompiled MVC
views, the best approach is to actually create an MVC project for
that library, instead of a library project. You'll never actually run
it as an Mvc app, but the fact that it comes with the right set of
config files allows intellisense and other things to work a lot
better than in a library project.
You can then add a reference to that 'MVC View project' from your real
MVC app.
And note that you need to install the 'RazorGenerator.Mvc' package
into the library, not the main MVC app.
Programming ASP.NET MVC 4 written by Jess Chadwick tells that
In the ASP.NET Web Forms world, you can achieve this by creating user
controls or custom controls that can be compiled into standalone
assemblies. These assemblies can be distributed across projects,
thereby enabling their reuse across projects.
The Web Forms view
engine offers the ViewUserControl class, which can be leveraged to
create such components for the MVC framework. The Razor view engine in
ASP.NET MVC, however, does not offer any such method out of the box.
and suggests using Razor Single File Generator visual studio extension, another one but the similar to Razor Generator approach.
I have an existing website coded in ASP.Net 4.0 Webforms, and would like to add an "ASP.Net Dynamic Data Entities Web Application" (project templates of VS2010 to my actual project):
So my question is, what are the steps to "merge" the 2 projects or integrate the "ASP.Net Dynamic Data Entities Web Application" to my actual webforms.
I think I must merge my Global.asax.cs files and web.config file + move rest of the files. Is that correct ?
I already read that post (that may be outdated?):
http://www.hanselman.com/blog/IntegratingASPNETMVC3IntoExistingUpgradedASPNET4WebFormsApplications.aspx
Thanks for your answers :)
(the original title of this post was: “ASP.Net Dynamic Data Entities Web Application” integration with an existing Webforms)
I've read Scott Hanselman's article which you've provided in your question and yes the same technique still applies today, here are a few steps/considerations which should help you along the way:
When you create the new ASP.NET Dynamic Data Entities Web Application make sure that it's the same .NET Framework version as your Web Forms project, to avoid version conflicts.
Remember to add a reference to all the required libraries that you've been using in the Web Forms project.
Now it's safe to copy all the necessary .aspx pages to the new site.
There is some automatically generated code inside the Global.asax of a Dynamic Data project which is used to configure ASP.NET routing, it may be useful later so instead of replacing it with your Global.asax use a tool like WinMerge to merge the two files.
When an ASP.NET application is published using the publish option in Visual Studio a series of DLLs are produced in the BIN folder on the web server. What is the difference between the DLLs generated by Visual Studio specifically for ASP.NET and a standard Class Library?
I am wanting to reuse code in classes that are contained in an ASP.NET application.
One option for me is to convert the ASP.NET classes into a class library and hence the reason for this question. The other option is to use a web service to expose the functionality required by other applications.
There is no difference between DLL's generated by ASP.NET and a standard class library. Although the web application project produces a DLL, which can't really be reused (well it could, but it contains the code-behind of your pages and user controls, but not the markup), every other DLL can be reused.
Using services and implementing Service Oriented Architecture (SOA) is another option too, so it really depends on what your requirements are, and what you are trying to reuse.
The main reason for choosing a class library over built in classes is so they can be shared with other projects, or the DLL could be distributed for further use.
The benefits of a class library that I can think of are:
Tidier project structures
Quicker Project build time
Different versions of your library can be referenced, hence resilient to upgrades
I generally use web services for projects that require communication between applications/servers, rather than wrapping common code.
You should extract the code you want to reuse in a separate assembly and reference it in the web project and in the other project. Don't use the assemblies with the web pages and other application specific code in another application.
I'm looking at building some web user controls with an eye toward re-use, but I can't seem to add a Web User Control in my class library in VS2008. Is there a way to work around this problem, or is there a better approach to creating reusable controls?
You can create either Web User Controls or Web Custom Controls that encapsulate the functionality you need. The main difference between the two controls lies in ease of creation vs. ease of use at design time.
You should maybe consider creating a Web Custom Control library. There is a walkthrough for creating a web custom control using the Web Control Library template.
According to the MSDN article "Recommendations for Web User Controls vs. Web Custom Controls" these are the differences between the two types of controls:
Web user controls are easy to make,
but they can be less convenient to use
in advanced scenarios. You develop Web
user controls almost exactly the same
way that you develop Web Forms pages.
Like Web Forms, user controls can be
created in the visual designer, they
can be written with code separated
from the HTML, and they can handle
execution events.
However, because Web
user controls are compiled dynamically
at run time they cannot be added to
the Toolbox, and they are represented
by a simple placeholder glyph when
added to a page. This makes Web user
controls harder to use if you are
accustomed to full Visual Studio .NET
design-time support, including the
Properties window and Design view
previews.
Also, the only way to share
the user control between applications
is to put a separate copy in each
application, which takes more
maintenance if you make changes to the
control.
Web custom controls are compiled code,
which makes them easier to use but
more difficult to create; Web custom
controls must be authored in code.
Once you have created the control,
however, you can add it to the Toolbox
and display it in a visual designer
with full Properties window support
and all the other design-time features
of ASP.NET server controls.
In addition, you can install a single
copy of the Web custom control in the
global assembly cache and share it
between applications, which makes
maintenance easier. For more
information see global assembly cache.
Follow the following steps (from this post by Phil Haacked):
Close VS.NET 2005.
Open the directory C**:\Program Files\Microsoft Visual Studio 8\Web\WebNewFileItems\CSharp** (assuming a default installation of VS.NET).
Open the CSharpItems.vsdir file in Notepad. Select the text and copy it to the clipboard.
Now open up the file C:\Program Files\Microsoft Visual Studio 8\VC#\CSharpProjectItems\CSharpItems.vsdir and paste the contents of the clipboard underneath the existing text.
Now copy the contents of C:\Program Files\Microsoft Visual Studio 8\Web\WebNewFileItems\CSharp (excluding CSharpItems.vsdir) into the folder C:\Program Files\Microsoft Visual Studio 8\VC#\CSharpProjectItems.
Now “Web User Control” should be an option when you select Add | New Item.
Reference: http://haacked.com/archive/2006/02/07/addingwebusercontroltoaclasslibraryinvs.net2005.aspx
As platte's link mentions, if you're going for reuse then Web User Controls aren't very good. The ascx file has to be manually copied to every project you want to use them in, or you have to hack your way around that.
It's better to use System.Web.UI.WebControls.WebControl which is what you get when you add an "ASP.NET Server Control". These are designed for reuse. If one of the existing framework controls fits the bill for the most part and you just need to extend the functionality of it, then add an "ASP.NET Server Control" and change it to inherit from Panel or Menu or whatever.
If you're still determined to get reusable Web User Controls to work, then this article by The Gu should set you on the right path.
There is a project template called "ASP.NET Server Control" that I assume you can use...
--larsw
You can do anything in a class library.
Add reference to System.Web
Create your new Control class that inherits
from WebControl or HtmlControl or
whatever.
That's it. You now have a reusable control for ASP.NET.
You could do some special things like add attributes to your class and properties, but they are really not needed.
[DefaultProperty("Text")]
[Category("...")]
[DefaultValue("")]
You could using virtual path providers but you you should consider whether it really is worth your wile. Consider this codeproject article on the subject.