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.
Related
I need a Solution with one main .Net Core Web Application and areas to be created, but each areas has to be a .Net Core Web Application. The reason I need this is, the projects in the area needs to have separate dll and other supporting files in the bin of Main project.
Is that possible in .Net Core ?
If so, I have tried to imply the same, but each project is created with a Main method in Program.cs, which fails my build stating "Multiple entry points in my solution".
Sounds like you need Features. This will let you group and separate your Areas into different folders and then move these into different shared projects or portable libraries. You can then reference and use these in your Main .NET Core Web App.
These are not standalone Web Applications as you asked for, but it's the best way i can think of, in order to separate the different components in your application.
There can only be one entry point in a C# program.
If you have more than one class that has a Main method, you must compile your program with the /main compiler option to specify which Main method to use as the entry point. For more information, see /main (C# Compiler Options).
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 a several projects full of .ascx UserControls that contain C# code blocks rather than having codebehind pages. I'm looking to consume a WCF service I've created, and I've added the Service Reference to the project, but I'm having trouble referencing it on the page using various directives.
Is this possible? The UserControls are used inside of WebParts in SharePoint 2010 if that makes a difference. Web service is deployed to _vti_bin if that matters as well, and is definitely operational (I've tested the exposed methods via a console app and through deployable projects which utilize codebehinds).
If this were not being done for SharePoint (yes, it makes a huge difference!) then I'd say that you should create a class library project, add the service references to the class library, and then use the class library from your user controls.
However, since it's SharePoint, you have to be concerned about deployment of DLL files.
I think some variant on my suggestion would work. You would have to sign the class library and place into the GAC, or you should arrange to bin-deploy it. In either case, I believe you'll want to include your controls and this class library in the same Feature.
I have a web application that contains a bunch of classes in the App_Code folder. I compile the project and publish it to the IIS server.
I want to share some of the code in the app_code folder with another application on the server and therefore I think I need to register an assembly in the GAC.
What is the best way to do this? I have read this article: http://msdn.microsoft.com/en-us/library/Aa479044, which suggests a number of options?
Put the code in a class library, and add the library as a project reference to both applications.
Side Note:
If you need to access the request or response, etc. import the Sysyem.Web library and use the HttpContext object. This will give you most, if not all the information available to the page.
You'll have to move the code into a separate project, which will output a library.
If you have any references to dlls related to the ASP .Net or web in general, you can reference them from that library.
The code might not compile in the first, but you can refactor it, it really depends on how tight is with what is in App_Code.
You can then reference that library on the Web Site (you'll have to refactor here too some things). The library, once is signed, can be added to GAC also.
The solution for me was to expose the shared functionality in a web service.
I am new to Silverlight. We are migrating our project to Silverlight. We are just changing our presentation layer. (ASP.NET WebForms site to Silverlight web application). So our other class libraries having business & data access layer will remain as it is.
Firstly I added a Silverlight web application to my solution. It created 2 projects: PM_Tool and Pm_Tool.Web. Now I need to add project references of the Business and Data Access layers to this, since I need to access them in my MainPage.xaml.cs.
But I can't add a reference to Pm_Tool - I get the following message:
You can only add project reference to other Silverlight projects in the solution.
I then added project references to Pm_Tool.Web, but I can't access the business layer objects in MainPage.
Can anyone help how I can proceed further?
A Silverlight application can only reference other Silverlight projects. This is simply because Silverlight uses a lighter version of the .NET framework; if you could reference 'full' .NET projects then it would be required to support the entire framework. Microsoft have made a design decision to limit the functionality - presumably this is to reduce the installation & runtime footprint of Silverlight.
Having said that, it's quite likely that most of your code will still run in Silverlight. You should create "Silverlight Class Library" projects and include your classes into those projects. You will soon see which (if any) classes are using parts of the framework that are not supported by Silverlight. From there, implement workarounds.
Of course all your data access and server side code must remain in your 'Web' project. Silverlight implements a correct client-server model and doesn't allow you to 'cross the boundary' in the same way that ASP.NET WebForms does. Your Silverlight application runs solely in the browser - anything that needs to happen 'on the server' must happen in the 'Web' project. Your Silverlight application posts and gets information from the 'Web' project via WCF (or WebClient, etc).
Unless you have a very well designed ASP.NET solution, I would expect that your transition is not going to be as simple as 'just changing our presentation layer'.
you can only add referances to other silverlight assemblies. you are not allowed to add referances to "normal" windows assemblies--asp.net or WPF, or winforms (etc.) however, you ARE allowed to add referances of silveright assemblies to other projects.
you are going to have to make silverlight versions of the assemblies you want to add. the main reason for this is the security model.
now, the problem you may run into is that since silverlight is really a subset of WPF is that many of the classes that you would like to use will not be available. however, there are ways around this--using webservices, etc.