My company has visual studio asp.net web site projects. When adding a new web form using the default webform template it will automatically create the codefile with the partial class name using the path and the filename you selected. For example, if you added a new web form named Default.aspx to the path User/Feature/ the partial class name will be User_Feature_Default. This works fine. The issue (which may not be an issue) is that of course if you move those files around it will not update the partial class name. Makes sense. Visual Studio is only going to do so much tweaking. My question is whether or not our development group should update these partial class names when the files are moved into new folders mainly for consistancy sake? Will this cause any other problems? I can't think of any.
If there is a possibility of adding new .aspx pages with the same name in those locations, I would advocate renaming. I've run into issues in the past where I had Copy+Pasted a file to have a template to start from. The file name changes, but the class name and .aspx Inherits attribute remain the same.
Because the code-behind pages are partial classes, it will happily let you add multiple classes. But I think those then end up being compiled into a single page class which can spell problems if you have Load/Init logic that should only fire on one of the pages, or if you have functions named the same thing.
Related
Building a medium complexity single page app.
My project has similar but different functionality is some areas such that the logical (as in reasonable) name for pages overlaps. To organize the project I place the different functionality in sub folders and this has the side effect of allowing me to name the page files the same.
Consider this example:
../mypage.aspx
../subdir1/mypage.aspx
../subdir2/mypage.aspx
Each myPage.aspx has this (snippet):
<%# Page Inherits="mynamespace.mypage" %>
And each code behing has this:
Public Class mypage
Inherits System.Web.UI.Page
End Class
It occurs to me this may get confusing, the alternative would be to make up some prefix or suffix to distinguish the files.
../mypage.aspx
../mypageFN1.aspx or ../FN1/mypageFN1.aspx
While I may choose to do that my question is does naming pages the same cause any problems when running the website?
What if a user could have two of the pages open at once (as in tabs)?
My thought is the class names only exist during page fetch operations on the server so there is no possibility for collision, but I am not confident in that assessment.
My confusion is not new here or arround the web, yet, i have some questions for which i did not find answers anywhere:
The first question is:
Why is Inherits necessary on CodeFile and not on CodeBehind?
I read: http://msdn.microsoft.com/en-us/library/vstudio/ms178138(v=vs.100).aspx and some more pages, and i understand that CodeFile is for source code and for compilation on the fly while the other is for an assembly. This raised me another question:
Why do everyone say that CodeBehind must be an assembly if i find
File.aspx.cs everywhere including in a test project i have and it
works like a charm? Is this a compiled assembly?
But, as of the first question, and based on the url i supplied, i might understand, why the Inherits is necessary. I assume the compiler must know what is the name of the partial class to compile later. Makes sense. Yet, shouldn't it be necessary on CodeBehind as well? If we are going to merge the partial classes, i suppose i should give the name of the one i want to merge. I even tried adding another partial class to the .cs file and it compiled/ran well.
Am I missing something here?
I also read that CodeBehind is not used anymore and it's CodeFile, the new one.
Any .NET guru to help me?
Thank you all in advance.
UPDATED:
I tried to implement events using no Inherits on CodeBehind. It didn't work. This makes more sense. But, it doesn't complain on compilation, while CodeFile does. Is there any reason for this?
Inherits property carry the class name which written inside the code behind file. you can have multiple classes in same code behind file and inherit in two different .aspx file
CodeBehind file provides the code behind for the aspx page. When you add a new "ASP.NET webpage with CodeBehind", let's call it NewPage.aspx, 2 files are also created, called NewPage.aspx.cs and NewPage.aspx.designer.cs. NewPage.aspx.cs is your CodeBehind file. As Vijay stated, since a (C#) file can have multiple classes (which is different from Java, where a class file can only contain 1 class, and the class name have to be matching the file name), Inherits=[namespace].[class] indicates which class you want to actually use for the web page.
The CodeBehind attribute is for Web application projects. The CodeFile attribute, on the other hand, is for Web site projects.
Is it possible to compile a web application project .ascx (user control) into a dll?
I want to do the following:
Use the same control in multiple websites
Embed css and .js as resources into the control
Be able to update super easy. If the user control updates, I just want to update 1 .dll
I have successfully followed this article, http://msdn.microsoft.com/en-us/library/aa479318.aspx.
However, that uses web site projects, and I cannot embed js css as resources into web site projects.
Any ideas? Am I going about this wrong, should I change the approach?
Conversion is easy, and could even be fully automated. It simply requires changing a few settings and base classes in the DLL Project you want your ASCX controls embedded in.
1... For each UserControl, set the ASCX file's Build Action (under Properties) to "Embedded Resource", and delete its associated designer file.
2... Save the project.
3... Right click the project and choose "Unload Project".
4... Right click it again and choose the "Edit *.csproj" option.
Change sections that look like this (where the asterisk represents your class name):
<Compile Include="*.ascx.cs">
<DependentUpon>*.ascx</DependentUpon>
<SubType>ASPXCodeBehind</SubType>
</Compile>
to look like this
<Compile Include="*.ascx.cs" />
That will cause the code-behind files to be compiled independently of the ASCX files.
5... Save changes, and right click the project and choose "Reload Project".
6... Open all your "*.ascx.cs" files and make them inherit from the following custom UserControl class, instead of the System.Web.UI.UserControl class (you may need to locate parent classes to complete this step).
public class UserControl : System.Web.UI.UserControl
{
protected override void FrameworkInitialize()
{
base.FrameworkInitialize();
string content = String.Empty;
Stream stream = Assembly.GetExecutingAssembly().GetManifestResourceStream( GetType().FullName + ".ascx" );
using (StreamReader reader = new StreamReader(stream))
content = reader.ReadToEnd();
Control userControl = Page.ParseControl( content );
this.Controls.Add( userControl );
}
}
This base class will take care of loading and parsing the embedded ASCX file.
7... Finally, you may need to place ASCX files in subfolders so that their resource names (automatically determined by folder path) match the full type name of their associated class (plus ".ascx"). Assuming your root namespace matches your project name, then a class named "ProjectName.Namespace1.Namespace2.ClassName" will need its ASCX file in a subfolder "Namespace1\Namespace2", so it gets embedded with the name "ProjectName.Namespace1.Namespace2.ClassName.ascx".
And that's it! Once you compile the DLL and include it in another project, you can instantiate instances of your user controls using the "new" operator, like any other class. As always, your control will be "caught up" to the current page event once added as a child control to the page or another control on the page.
It is difcult to use user controls in this way due to the markup ascx file. If you want to create reusable control libraries your are much better off creating custom controls.
Another way would be to convert user control to the custom control. There is an nice article on MSDN: Turning an .ascx User Control into a Redistributable Custom Control which describes exactly how to do that. Here is the summary:
Write your user control as you normally would, typically using the Visual Studio designer.
Test it using a simple page before trying to deploy it.
Deploy the application to precompile it.
Grab the user control's assembly produced by the deployment step,
and you're essentially done: You have your custom control.
Finally, use your custom control in other apps the same way as you
always use custom controls.
Hope this helps.
I had to do it once and I followed this article
http://www.codeproject.com/KB/user-controls/EmbeddedUserControl.aspx
It's based on the possibility of mounting a virtual file system on different places (an assembly, database, etc)
There are quite a few articles out there on how to do exactly that:
http://www.nathanblevins.com/Articles/Compile-a-Web-User-Control-into-a-DLL-.Net-c-.aspx
http://blogs.msdn.com/davidebb/archive/2005/10/30/487160.aspx
I know this is old, but yes its possible.. I do it all the time, see https://kocubinski.wordpress.com/2013/05/06/compile-asp-net-webforms-ascx-usercontrols-into-assembly-for-re-use/
This is driving me absolutely nuts.
I created a new WAP project in VS 2008. Copied over the files in my Web Site Project. Added any required references. Tried to convert the Web Project to a Web Application using the "Convert to web application".
None of my user controls are able to see methods in their code behind. They don't even see them so I get errors everywhere saying it doesn't know what this or that method is.
Example:
<%=CreateMenu(xxx.WebMenuType.Occasion, "menuShopOccasion", "Occasion") %>;
That is in my Header.ascx
And so it errors out because it has no clue what CreateMenu is!
In my Header.ascx.cs it's there and was being referenced with no problem in my old Web Site Project:
protected string CreateMenu(xxx.WebMenuType menuType, string menuID, string title)
{
...
}
It's probably a namespace problem. Make sure that the Inherits attribute in your <%# Page ... %> declaration refers to the correct path to the code behind file, including the namespace. The designer file must also be in the same namespace as the code behind.
I am not entirely sure this is your problem but....
you may be missing the .designer.cs files. For your example above there would also be a Header.ascx.designer.cs which contains a partial class (Header) which has all the declarations of the controls in the Header.ascx file?
I'm using VS2008 and want to create a web application (not a web site) with Code-Beside
but, the default mode of aspx is Code-Behind.
I have tried to change the CodeBehind=ClassFile.cs to CodeFile=ClassFile.cs in the header of aspx's <%#Page%> part, and deleted the aspx.designer.cs file,but if I added a server control to the page, the compiler is also send me an error of no member defined.the cs file is the orinal file of codebehind, it is partial class.
You don't want to delete aspx.designer.cs you want to delete the aspx.cs file, then place a similar file next to it and declare it as a partial class. designer.aspx.cs is still required to provide you direct access to controls placed within the page, rather than going through FindControl.
You definitely don't want to delete the .designer.cs file, as this is where the server control definitions will be placed.
In general the codebehind model is much better as it makes the code easier to find, use and maintain.