After reading the answer here, I understand that, if I register a user control (I guess I'm really trying to use it as a custom server control) like this:
<%# Register Assembly="MyDLL" Namespace="MyDLL" TagPrefix="myDLL" %>
Then only the codebehind is used, and the markup (.ascx) page is ignored. Why is this the case (it seems arbitrary), and how can I get around this problem without having to specify the Src="..." attribute in my Register directive? All I want to do is build a user control into a single assembly (a DLL) and hand that DLL off to another web site or web application project in such a way that the web site/app can use my user control. This should not be that hard, but apparently it is...
I am working in Visual Studio 2008, if it makes a difference.
Edit (prompted by the links in Rex's M's comments): it seems like most of the instructions for doing this kind of thing are applicable to VS2005, even the stuff on MSDN. My question is pretty much exactly stated here; is the answer provided on that thread correct
Is there any reliable, recent documentation describing this sort of thing for ASP.NET 3.5 and VS2008? I feel like using the latest versions is causing more confusion and difficulty than benefit.
The thread you linked to is indeed correct. The information which originally addressed .NET 2.0 and VS 2005 is still very applicable. .NET 3.5 does not actually change .NET 2.0, just adds extra stuff. For things that are already in .NET 2.0, they are unchanged in 3.5.
It sounds like you want the functionality of a Custom Control. In a normal user control situation, the website needs an .ascx and that cannot be placed in a DLL.
I strongly recommend to take a look at custom server controls. Since for the purpose of sharing controls over multiple projects they are better suited in my opinion than user-controls. User controls are better for internal reuse, within the same web application (i.e. on multiple pages).
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
I know that in order to use most of the controls from the Ajax Control Toolkit, you need to include the ToolkitScriptManager control on your page, and it must be the Toolkit script manager, and not the standard script manager because the extended toolkit version contains extra (java)scripts which enable the controls to work and communicate properly.
My problem is that I keep coming across projects at work from other developers where they used the standard ASP ScriptManager control, and added toolkit controls without switching over to the ToolkitScriptManager. I would have expected these projects to not debug properly, yet they are currently somehow working in test and production environments, and they do not actually break until I download them onto my freshly loaded dev environment from source control.
When someone asked me "Why do we need to replace these controls? They're working everywhere else." I could only shrug my shoulders, I have no idea why other projects are working with regular script managers.
As a side note, problems like this are what are pushing me into becoming a JQuery guy instead of a ACT guy.
Here is a question to answer since this is a Q&A site and not a discussion site: "How is it possible to run the ACT controls without an ACT script manager?" Personally, I would point to a glitch in Visual Studio of some kind, but I want to know if anyone else knows more.
ToolkitScriptManager inherits from ScriptManager and extends/improves its functionality.
You may safely substitute ToolkitScriptManager with ScriptManager just so long as you are not using any advanced feature provided by the ToolkitScriptManager.
What are those supposedly advanced feature differences you ask?
Check Here for your answer...
TMI Alert:
MS actually recommends replacing ToolkitScriptManager in certain instances if you are suffering from Out Of Memory exceptions and there are also a high number of System.Web.FileMonitorTarget objects in existence. These objects are used to check and see if the page was modified (you can see how it relates to AJAX), but these objects should go away and not be maintained.
For some reason, if you're using the ToolkitScriptManager, there are instances where FileMonitorTarget objects just don't go away and end up contributing to server memory problems, but neither I nor they fully understand why replacing the ToolkitScriptManager with ScriptManager actually helps in these scenarios, but just so long as it works, we won't continue to ask questions...
Are there any third-party Templating Engines for Asp.net like we have smarty,savant for php ?
Spark: http://sparkviewengine.com/
Your question does not explicitly states what "breed" of ASP.NET you are using, so I guess it is most likely web forms. If this assumption is correct, I would not recommend for you to replace the default view engine. In order to make good use of the build in controls, you really want to keep the abstraction where HTML like elements can be marked runat=server and accessed from the server side code.
If you happen to use ASP.NET MVC, the picture is completely different. Here, there are lots of different view engines available - including NDjango, NHaml, Spark. If you are the type of web developer who care about the templating engines, you are likely to prefer ASP.NET MVC as a whole, and you might want to check it out before starting your next project.
Do you guys know about an ajax toolkit (or something similar to the m$-ajaxtoolkit) for mono??
Microsoft's ASP.NET AJAX Control Toolkit works on Mono, and is open source (Ms-PL). That doesn't preclude the use of jQuery, though. There are actually several third party AJAX libraries and control toolkits that support Mono, and many are compatible or work in conjunction with ASP.NET AJAX.
I agree with Brian, but want to add that you should read Dave Ward's series on jQuery and ASP.net. He really distills the essence of what you can do with jQuery, PageMethods, and WebForms without MS Ajax. These ideas are directly applicable to the Mono / Linux environment.
Here's a list of essential posts:
Using jQuery to directly call ASP.Net Ajax PageMethods
Use FireBug To Learn jQuery
Simplify calling ASP.NET Services with jQuery
I'd recommend rolling your own using jQuery. That's what m$ is doing now anyway.
Debugging Mono website
Do you remember, that you have no development environment in this machine? You can install it, or download Mono liveCD with openSuse. But before doing it, please note, that GTK# (it’s devenv) is not very user friendly. It even worse, then Eclipse. So let’s try to understand first whether we can fix small compatibility problems without entering code.
The most convenient method to debug web site on Mono is by using XSP and XSP2 mini web servers. Just enter the directory of the site and run it. By default you’ll be able to access the site by using ... (it also be written for you). Enter and notice whether you have any errors in console. No? Keep doing
The most common problem is “error 500” with nonsense stack. If it contains ScriptManager error Type not found, the problem is in Web.config file. Try to regenerate it to be compatible to Mono (for example, Mono has different version of System.Web.Extensions assembly. In ASP.NET 3.5 it has version 3.5, Mono has only 1.0.61025.0 (the old AJAX.NET). To recreate your web.config all you have to do is to execute “mconfig af AJAX Web.config” It will create default web.config file, supports System.Web.Extensions (AJAX features).
Not helped? Keep doing. Let’s look another time into the stack – if it contains errors in “EnablePageMethods” or “ShouldGenerateScript” or “EncryptString” – the problem is serialization. Mono has very limited support for JSON, XML and SOAP serialization. Try to look into your code and notice if you have classes, marked with [Serializable] or you are transferring your own classes by using PageMethods. If so, replace it with regular strings (my grandma serialization).
Is the source code for the common login controls available?
Those are the controls which are available under Login section in Toolbox:
Login,
LoginView,
PasswordRecovery,
LoginStatus,
LoginName,
CreateUserWizard,
ChangePassword
Eventually could you point me to a good source of custom implementation of functionality that those controls provide, or some guidance on implementing this functionality without using the mentioned controls.
I am using Visual Studio 2005 (.net2)
I will be using SQLMembershipProvider as the MembershipProvider but that probably should make no difference.
"the entire framework is available" is not true. :)
The source code for the entire framework is available. The link below provides some details as to how to access:
http://blogs.msdn.com/sburke/archive/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code.aspx
I am going to give this a qualified "NO".
I have gone down the road of implementing an implementation of the Login server control using reflected source as a starting point (this was before symbol server integration).
Things seem to go swimmingly, with a few reflection hacks to get to core framework members that obviate reams of code.
Until you get to the designers. That infrastructure is a minefield and gets wide and deep with a quickness and is filled with even deeper buried internal types that need implementations or reflection hacks.
Ultimately wound up with a working control that I could extend but would never want to maintain.
The effort was not wasted; I learned a lot about how over engineered server controls are designed.
And then I just shifted a login control to template mode and got everything I needed to get done in a few lines of code. ;-)
Except as a learning experience I would certainly recommend against going down that road.
Good luck.