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.
Related
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 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 have a web application, which has a user control and web page logic to be used on multiple web applications. The reason I want to do this is that I want the other web applications to reference this one since the html/css of their web pages varies.
First of all I wanted to ask if this is possible since it is a web application and not a class library.
Secondly if it is possible how do I refrence the web page logic to the htmls of the other web applications?
How about adding the Web User Control to a Class Library and referencing that Class Library from the website ?
Here are instructions by Haacked on how to add a User Control to a Class Library: http://haacked.com/archive/2006/02/07/AddingWebUserControlToAClassLibraryInVS.NET2005.aspx
Also here is a post by Guthrie about Building Re-Usable ASP.NET User Control and Page Libraries with VS 2005 and I think it's worth a look.
[Update]
I found a better tutorial on Creating and Using User Control Libraries. I think that this article is more concise than the other one by Guthrie (also this one is also by Guthrie)
Compile and deploy your asp.net website which will produce one assembly per code-behind.
Pick the assembly of the code-behind class you want to re-use and drop it into the \bin folder of your 2nd web-app in which you want to reuse it.
Now this assembly will have a partial class which you can merge with the code-behind of an existing web-page. Just ensure the naming hierarchy are matching.
Is there a way I can use the sharepoint controls in a ASP.NET web application like any other controls that come out of box for ASP.NET? If yes, what are the pre-requisites I need to install?
Thank you,
Harsha
Yes, you can use SharePoint "controls" in an ASP.NET application, as long as the application is running in SharePoint.
In other words, the prerequisite is SharePoint.
Most controls have internal dependencies on SharePoint (i.e. they use SPContext or SPWeb internally). Also, since they are contained within the Sharepoint Assemblies, you can not just take the .dlls and put them in your app.
In short: In most cases, it will be better to re-build them using reflector. Which one are you looking at?
What specific controls are you referring to? Those that you find in SharePoint Designer?
If you are referring to Web Parts in WSS v3, those that are using the ASP.NET Web Part as the base web part (the recommended approach) may work fine in ASP.NET since the Web Part class inherits from Panel which inherits from Web Control (going from memory here) - all ASP.Net classes. It would just depend on whether the web part has any SharePoint specific code which is highly dependent upon the web part.
Host the application in SharePoint's _layouts directory (see this video for more details). Your ASP.NET app will then be "running in SharePoint" and have access to all SharePoint controls.
Note that some controls don't work unless they are running on an actual SharePoint page.
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.