I know why runat="server" is currently required (ASP.NET why runat="server"), but the consensus is that it should not be required if you incorporate a simple default into the design (I agree of course).
Would it be possible to modify, extend, decompile and recreate, intercept or otherwise change the behavior of how ASP.NET parses ASPX and ASCX files so that runat="server" would no longer be required? For instance, I assume that a version of Mono could be branched to accomplish this goal.
In case specific requirements are helpful, the following highlights one design:
During parsing, when configured namespace tags are encountered (such as "asp"), default the element's runat property to "server"
During parsing, when configured namespace tags are encountered (such as "asp"), if the element's runat property value is available, then that value should be used in place of the default
New page-level setting introduced (can be set in the page directive or web.config) that specifies the default runat value for a specific namespace tag
I'm afraid you'd have to modify the entire page parser to accomplish this, and I don't think that's possible.
On the other hand, you should be able to create your own. See the buildProviders Element and the BuildProvider class. You should be able to create your own build provider for .aspx pages and use it to replace the built-in provider.
Unfortunately, the PageBuildProvider class used by ASP.NET is internal, and the PageParser class that it uses to parse pages is sealed. You'll be entirely on your own.
Consider that runat="server" has been in ASP.NET for a decade now, and I think you'll see that this won't change anytime soon.
You'd also lose Designer support, but maybe you don't care about that.
So far as I know, there are no hooks deep enough in the ASP.NET Page handling process that would allow this. I know of no way to override or extend the parsing or processing of actual aspx/ascx code.
While ASP.NET is fairly flexible and lets your override many default behaviors (like how ViewState is saved/loaded, where Session is stored, etc) this is not one of them.
However... technically the Page object is just another HttpHandler. You could write your handler and do anything you wanted with it. All you have to do is implement everything the Page class does and then throw in this extra functionality. :) Alternately, pull out Reflector and dig through the Page object's ProcessRequest method and see where it is actually parsing/initializing the objects declared in aspx and you might get a clue how to implement the functionality you're looking for. But I suspect you'd be wasting your time.
In ASP.NET if the code and the asp.net markup is in one ascx file for example for a user control,would it perform poorly compared to a User control with Code Behind using a cs file and a designer.cs file?
The difference is in the initial compilation time; when your app first starts up.
With a code-behind file you can pre-compile things and deliver a dll to the server that's ready to go. With inline code, the framework will have to compile your code into an assembly when the app starts. But after this point compiled code is compiled code, and it just doesn't matter.
for performance it will not make any difference, although for maintainability reasons, you should keep your code behind separated from your markup.
An interesting fact - Microsoft sometimes suggests you create a code-behind assemblies for your ASP.net pages for maintainability and presentation/business logics separation.
However, when you take a look at how SharePoint is built, its pages (for instance, /_layouts/workflow.aspx) are full of inline code.
They actually do reveal that the speed of inline code is the same as code-behind:
Another myth is that codebehind is
faster than inline, which is
absolutely false. It doesn't matter
where your code for your ASP.NET
application lives, whether in a
codebehind file or inline with the
ASP.NET page.
This makes me think that performance and maintainability is not always the main reason why you choose inline code over code-behind.
Sometimes when I'm editing page or control the .designer files stop being updated with the new controls I'm putting on the page. I'm not sure what's causing this to happen, but I'm wondering if there's any way of forcing Visual Studio to regenerate the .designer file. I'm using Visual Studio 2008
EDIT: Sorry I should have noted I've already tried:
Closing & re-opening all the files & Visual Studio
Making a change to a runat="server" control on the page
Deleting & re-adding the page directive
If you open the .aspx file and switch between design view and html view and
back it will prompt VS to check the controls and add any that are missing to
the designer file.
In VS2013-15 there is a Convert to Web Application command under the Project menu. Prior to VS2013 this option was available in the right-click context menu for as(c/p)x files. When this is done you should see that you now have a *.Designer.cs file available and your controls within the Design HTML will be available for your control.
PS: This should not be done in debug mode, as not everything is "recompiled" when debugging.
Some people have also reported success by (making a backup copy of your .designer.cs file and then) deleting the .designer.cs file. Re-create an empty file with the same name.
There are many comments to this answer that add tips on how best to re-create the designer.cs file.
Well I found a solution that works, though I don't really like it. I had to delete the .designer.cs file then recreate an empty file with the same name. When I went back in and saved the aspx file again, the designer file was re-generated.
Dodgy!
I use the following method which works everytime:
Select all of the code-in-front (html markup etc) in the editor of the aspx/ascx file.
Cut.
Save.
Paste.
Save.
Recompile.
I recently saw that I was having the same problem. Visual Studio 2010 was refusing to update the designer file.
As it turns out, VS doesn't modify the designer file for a page that uses CodeFile (run off of pages) instead of CodeBehind (DLL). This is true no matter how many times you close VS, reload the project, re-create the control(s), or modify a file. Nothing would prompt VS to regenerate the designer. It's as if it doesn't create the designer file for CodeFile pages but does require it to be there.
I changed it to CodeBehind and saved the page. The designer file updated immediately. Then I just changed it back and everything was still golden. This behavior seems to be new with VS 2010 / .NET 4.0 as VS 2008 by default didn't suffer from this.
It's this part:
<%# Page Language="vb" AutoEventWireup="false" CodeFile="YourPage.aspx.vb" Inherits="YourPageClass" %>
Change CodeFile to CodeBehind, save, and then revert.
There is another possibility: You may have an error in your .aspx file that does not allow Visual Studio to regenerate the designer.
If you switch to Design View, it will show the control as unable to be rendered. Fixing the control (in my case it was an extra quote in the properties) and recompiling should regenerate the designer.
Most of the solutions here don't work if you're running Visual Studio 2013 and possibly 2012. Microsoft probably introduced some optimizations to make the IDE snappier, consequently they've reduced the number of cases that trigger the code generator. The following scenarios that used to work no longer do:
Delete the aspx or ascx file -- No longer checks for this case
Cut all the content and repaste into the aspx or ascx file -- No longer works, no change in the references
Convert to Web Application -- Option no longer available
Arbitrarily changing content on the aspx/ascx file -- No longer works (see 2).
The solution is surprisingly simple, but it's slightly cumbersome. In order to trigger the code generator, change something that would require the designer.aspx.cs to be generated. Changing content that doesn't affect code, such as a CSS style or adding text, won't trigger the code generator. You must change a referenced control. Here's how to do it:
In the ascx or aspx change the ID of the control
<asp:HyperLink ID="MyLink" runat="server" NavigateUrl="~/Default.aspx" Text="Home" />
to
<asp:HyperLink ID="theLINK" runat="server" NavigateUrl="~/Default.aspx" CssClass="tab" Text="Home" />
Go to the ascx.cs or aspx.cs and make sure you rename all references to "MyLink" to "theLINK" as well. Save and do build and the you should be good to go.
the only way I know is to delete the designer file, and do a convert to web app. However when you do this, it usually pops up with the error, as to why it didn't auto-regen in the first place, its usually a control ref that isn't declared in the head of the page.
Convert to Web Application did not work for me.
Deleting designer.cs and pasting a blank designer.cs did not work either.
But yes this worked:
Select all(Default.aspx)
Cut
Save Default.aspx
Paste
Save Default.aspx
Done. New designer.cs generated. :)
I often found that copy/pasting caused this behaviour for me. Most cases can be solved by editing the ID of a server control (just add a character, then delete it).
Also remember that control inside things like Repeaters aren't visible in the designer file.
And yes, there are cases where you need to do the delete-the-file magic listed above - but the name-change solution will work most of the time.
My experience is that if you want to do like in this article, like stated above.
Your markup file (aspx/ascx) has to include the CodeBehind="MyPage.aspx.cs" attribute or else it won´t work. I blogged about it here.
I've found a way to solve this problem without changing any code or running commands like "Convert to Web Application" - and it's simple too!
What I found was that restarting Visual Studio often solves the problem, but sometimes it doesn't. In those cases, if you close Visual Studio and then delete all content in the "obj" directory for the web project before you open it again, it has always worked for me.
(when started again you just add a space and remove it again and then hit save to have the designer file properly regenerated)
(The following comes from experience with VS2005.)
If you edit an ASPX page while debugging, then the codebehind doesn't get updated with the new classes. So, you have to stop debugging, trivially edit the ASPX page (like add a button or something), then click Design View, then delete the button. Then, your designer files should be updated.
If you are having a different issue with VS2008, then I can't help.
When you are in design view, right click on the screen and hit refresh.
Another thing which worked was -
Manually delete & then Create a designer file in filesystem.
Edit Project file.
Add code to include designer
Eg: <Compile Include="<Path>\FileName.ascx.designer.cs">
<DependentUpon>FileName.ascx</DependentUpon>
</Compile>
Reload Project
Open as(c/p)x file in design/view mode & save it.
Check designer file. Code will be there.
If you are using VS2013 or later , make sure that the code referenced with attribute "CodeBehind" not "CodeFile", then do below steps
<%# Control Language="C#" AutoEventWireup="true" CodeBehind="yourControl.ascx.cs" Inherits="yourControl.yourControl" %>
create empty designer page (or clear it if it's already exists "yourControl.ascx.designer.cs")
in the ascx (or aspx) copy all code , the delete it, then save. re-past it again , then save.
the designer file should be populated now.
Select-all in the designer file and delete everything in the file, leaving it blank and then save
Select-all in the ASPX/ASCX file and cut everything and then re-paste it back
The designer file should have regenerated the code
Here is wat i experienced ,
Select the website folder right click in the Solution Explorer, select Convert to Web application for all the aspx file a designer file will get generated.
Sameer
Just to add to the long list of answers here - I've just run into this issue in VS2010 (SP1) with an .aspx file. I tried adding and removing standard ASP controls (which has worked in the past) but in the end, I had to remove one of the runat=server lines from an existing control (and save) to force the designer file to regenerate.
The solution the worked for me is:
I just copied the page and and pasted it in the same portion, then renamed the first page(what ever name) and renamed the copied page as the original page. Now the controls are accessible.
I've encountered the same problem for years now, working in Visual Studio 2008. And I've tried every "solution" on StackOverflow and dozens of blogs, just like I'm sure all of you have. And sometimes they work, and sometimes they don't, just like I'm sure all of you have encountered. And apparently it's still an issue in VS2010 and VS2012.
So finally, a couple of months ago, I decided enough was enough, and over a few weeks I built a tool called "Redesigner" that generates .designer files. It's open-source under the BSD license, with the source code available on SourceForge — free to use, free to steal, free to do anything you please with. And it does what Visual Studio fails to do so often, which is generate .designer files quickly and reliably.
It's a stand-alone command-line tool that parses .aspx and .ascx files, performs all the necessary reflection magic, and spits out correct .designer files. It does all the parsing and reflection itself to avoid relying on existing code, which we all know too well is broken. It's written in C# against .NET 3.5, but it makes pains to avoid using even System.Web for anything other than type declarations, and it doesn't use or rely on Visual Studio at all.
Redesigner can generate new .designer files; and it offers a --verbose option so that when things go wrong, you get far better error messages than "Exception of type System.Exception was thrown." And there's a --verify option that can be used to tell you when your existing .designer files are broken — missing controls, bad property declarations, unreadable by Visual Studio, or otherwise just plain borked.
We've been using it at my workplace to get us out of jams for the better part of the last month now, and while Redesigner is still a beta, it's getting far enough along that it's worth sharing its existence with the public. I soon intend to create a Visual Studio plugin for it so you can simply right-click to verify or regenerate designer files the way you always wished you could. But in the interim, the command-line usage is pretty easy and will save you a lot of headaches.
Anyway, go download a copy of Redesigner now and stop pulling out your hair. You won't always need it, but when you do, you'll be glad you have it!
https://sourceforge.net/projects/redesigner/
TL;DR;
Edit the Inherits attribute of the ASPX page's #Page directive and hit Save. Your designer file should be regenerated.
Ensure that Inherits = <namespace>.<class_name> and CodeBehind = <class_name>.aspx.cs
I was trying to do this on a Sharepoint 2010 project, using VS 2010 and TFS, and none of the solutions above worked for me. Primarily, the option, "Convert to Web Application" is missing from the right-click menu of the .ASPX file when using TFS in VS 2010.
This answer helped finally. My class looked like this:
namespace MyProjects.Finance.Pages
{
public partial class FinanceSubmission : WebPartPage
{
protected void Page_Load(object sender, EventArgs e)
{
}
// more code
}
}
And my #Page directive was (line-breaks here for clarity):
<%# Page Language="C#" AutoEventWireup="true"
CodeBehind="FinanceSubmission.aspx.cs"
Inherits="MyProjects.Finance.Pages.FinanceSubmission"
MasterPageFile="~masterurl/default.master" %>
I first changed the Inherits to MyProjects.Finance.Pages, hit Save, then changed it back to MyProjects.Finance.Pages.FinanceSubmission and hit Save again. And wallah! The designer page was regenerated!
Hope this helps someone using TFS!
Within the Visual Studio:
1) Remove your aspx.designer.cs file
2) Right click on your aspx file and select "Convert to Web Application"
This should add the aspx.designer.cs back and up to date.
If you get an error saying:
"Generation of designer file failed: The method or operation is not implemented."
Try close Visual Studio and then reopen your project and do step number two again
How to generate aspx.designer.cs in visual studio?
in solution explorer just right click and select convert to web application. It will generate all the designer files again.
Step 1: Select all your aspx code, Cut [ CTRL+X ] that code and Save.
Step 2: Again paste the same code in the same page and save again
Now your .desinger page will refresh with all controls in .aspx page.
Delete the designer.cs file and then right click on the .aspx file and choose "Convert To Web Application". If there is a problem with your control declarations, such as a tag not being well-formed, you will get an error message and you will need to correct the malformed tag before visual studio can successfully re-generate your designer file.
In my case, at this point, I discovered that the problem was that I had declared a button control that that was not inside of a form tag with a runat="server" attribute.
This is a bug in the IDE; I've seen it since VS 2003. THe solution is simple though.
Save your files. Completely exit the IDE (make sure the process stops, task mgr.)
Reopen the solution, dirty the markup, save. Fixed.
I had two problems... outdated AJAXControlkit - deleted the old dll, removed old controls from toolbox, downloaded new version, loaded toolbox, and dragged and dropped new controls on the page (see http://www.experts-exchange.com/Programming/Languages/.NET/Visual_Studio_.NET_2005/Q_24591597.html)
Also had misspelling in my label control (had used 'class' instead of 'cssclass').
Ta
I had the problem that my new controls would not generate in the designer file when declared in the .ascx file. The problem was that i declared them in the code behind also. So deleting the declaration in the code behind solved my problem.
If you are like me and you add old .ASPX files to a more recent project.
You are probably going to forget some of the controls used on the page.
If so, first thing, if there are multiple files you are installing;
Fix one at a time first.
When you compile, fix errors generated. They will probably be the same
errors in all the files.
Next, if you have Designer files, delete all of the inserted - designer files.
Next, make sure there are not any other errors when you compile, other than
the designer files.
Finally right click your web project and click on Convert to Web Application.
This will insert the designer files you need.
These are the absolute best steps to fix the issues.
One thing that nobody's mentioned is to visit the page. I had my designer file stop regenerating because I was including a user control that didn't exist (for various reasons), and none of the things suggested here worked. For whatever reason, I didn't get any errors in Visual Studio - besides the one complaining about the fact that my client-side controls didn't exist because they weren't being regenerated, of course.
It took actually visiting the page to get ASP.Net to tell me the error.
Suppose you have 2 different ASP.NET applications in IIS. Also, you have some ASCX controls that you want to share across these 2 applications.
What's the best way to create a "user control library", so that you can use the same control implementation in the 2 applications, withuot having to duplicate code?
Controls have ASCX with HTML + code behind.
Composite controls will be difficult, because we work with designers who use the HTML syntax in the ASCX files to style the controls.
Tundey, we use SVN here. Do you have an example on how to implement your suggestion? How can SVN share the ASP.NET controls?
Thanks!
Scott Guthrie gives some great advice here on how to set up a User Control Library project, then use pre-build events to copy the user controls into multiple projects. It works really well.
http://webproject.scottgu.com/CSharp/usercontrols/usercontrols.aspx
You would need to create composite controls instead of .ASCX controls if you wanted to be able to use them in separate projects.
In addition to what Tundey said, NTFS Link shell extension is helpful when it comes to sharing a large chunk of content (e.g.: a folder with .ascx/.aspx) between otherwise independent projects. In case of code, i think making another working copy from VCS is preferable.
Have a look at this: http://www.codeproject.com/KB/aspnet/ASP2UserControlLibrary.aspx?msg=1782921
An alternative is to use your source control tool to "share" the ASCX controls between your webapps. This will allow you to make changes to the controls in either application and have the source control ensure the changes are reflected in the our webapps.
The biggest problem I've noticed with controls in ASP.Net is that you can't easily get designer support for both building the control and using the control in a site once you built it. The only way I've been able to do that is create an .ascx control with no code-behind (ie: all the server-side code is in a script tag in the .ascx file with the runat="server" attribute).
But even then, you still have to copy the .ascx file around, so if you ever need to make a change that means updating the file at every location where you've used it. So yeah, make sure it's in source control.
I managed to do this by sacrificing some of the ease of building the controls in the first place.
You can create a Control Library project that will generate a control library DLL for you. The drawback is that you have to create the controls with code only. In my last project, this was fine. In more complicated controls, this may be a problem.
Here's an example:
<DefaultProperty("Text"), ToolboxData("<{0}:BreadCrumb runat=server />")> _
Public Class BreadCrumb
WebControl
<Bindable(True)> _
Property Text() As String
'...'
End Property
Protected Overrides Sub RenderContents(output as HtmlTextWriter)
output.write(Text)
End Sub
Private Sub Page_Load(...) Handles MyBase.Load
' Setup your breadcrumb and store the HTML output '
' in the Text property '
End Sub
End Class
Anything you put in that Text property will be rendered.
Then, any controls you put in here can function just like any other control you use. Just import it into your Toolbox, make your registration reference, then plop it onto the ASP page.
I use StarTeam here and it allows you to "share" objects (files, change requests, requirements etc) across multiple folders. Not sure if Subversion (SVN) has that feature. If it doesn't, here's another trick you can use: create a junction from the primary location of the controls to a location in the other projects. A junction is just like a Unix symbolic link. You can download the tool for creating junctions in Windows from here
I have a suggestion.WE can use user control across multiples application by creating user control inside website project as normally.Then change the website property Use fixed naming and single page assemblies.Then we can use the user control dll into multiple applications.
I recently did a web application that just referenced the files (about 90 in total) from one web application (aspx, master and ascx) without too much of an issue. That said I was using a heavily modified version of the MVP pattern, a lot of interfaces and conventions to keep the complexity down, the same middle tier and one site was a subset of the other.
Big issues:
Master pages (and in turn designers and html view formatting) don’t work on a referenced file so you lose a lot of functionality. A pre-build step and a lot of svn:ignore entries was my hack around this. It was also a pain to get CruiseControl.NET to get the pre-build task to execute in the right folders.
Shared pages/controls need to be extremely aware of what they touch and reference as to avoid bringing in extra dependencies.
Both sites are locked together for deployment.
I now have to pray that the maintainer reads my pokey little document about the mess I made. It’s so far outside of what I’ve seen in ASP.NET projects.
I was under a massive time pressure to get it to work, it does and now both apps are in production. I wouldn’t recommend it but if you’re interested start at:
Add Existing Item, select some files, click on the Add button’s arrow and say Add as a Link.