views:

792

answers:

4

Although the classic ASP method of server-side includes works in ASP.NET, I get the impression it is not the preferred method. How am I "supposed" to be achieving the same effect?

This is how I'm doing it at the moment:
<!-- #include file ="functionlib.aspx" -->

+2  A: 

If you'e using ASP.NET MVC then Html.RenderPartial is your friend here.

http://msdn.microsoft.com/en-us/library/system.web.mvc.html.renderpartialextensions.renderpartial.aspx

A partial view can be implemented as a .ascx or an .aspx and putting the above call in your "primary" page basically says "get the output from this partial view and render it here".

Parial views can make use of the ViewData that your primary view received from the controller.

Martin Peck
Only if you're in ASP.NET MVC.
Mark Brackett
Er.....yeah. For some reason I read "MVC" in the question when it's clearly not there. Are people still doing old-skool ASP.NET??? ;-)
Martin Peck
lol @ Martin... er, yes. MVC is just a fad that everyone will stop using next week. Let the religious wars begin ;)
BenAlabaster
Martin, definitely people are using classic ASP.NET. MVC is still rough around the edges. Not everyone wants to go back to embedding inline C# into aspx pages. Some of us like code-behind and declarative controls. ;-)
x0n
Yep - ASP.NET MVC, while not being a "fad", is definately not for everyone. If you've got an investment in server controls etc then ASP.NET "classic" FTW! For me though, being closer to the metal is better and the MVC framework is cleaner. YMMV. In future I'll try not to inject the text "MVC" into questions when I reading :-)
Martin Peck
A: 

Sounds like what you need to be looking at is the entire concept of MasterPages.

Unless you are looking at just importing functions and other utilities (not html content). If that is the case (and you are using the code-behind model), you should just be able to include the appropriate file or namespace using the imports command at the top of your .vb page (adjust accordingly for C#).

TheTXI
+11  A: 

You now have a number of options that provide this effect, but in a different manner.

  • User Controls (.ascx)
  • Master Pages (.master)
  • Server Side Controls (.dll)
  • Class Libraries (.dll)
  • App_Code Classes (.cs/.vb)

Each are used for differently to achieve different things. It depends what you're really trying to do. Given the name of your include file, I'd imagine you're trying to include library functions that will be used within the context of your page.

Consequently you'd write a class library that contains the methods and import them into your application/aspx.

If you're looking at templating a page that will do most of the layout work to provide a body for differing content then you'll be interested in Master Pages.

If you're looking at templating controls that can be used in many pages, then you're going to be after User Controls.

If you're looking at templating controls that can be used by many users across many projects, then you'll be looking at Server Side Controls.

If you're looking at a library of classes/methods then you'll develop a class library or use an app_code class which can be JIT compiled the first time it's called. This could at a stretch be considered more like classic ASP, but really it functions more like a class from a class library as a single unit. You can call it from within your codebehind or within <% %> tags in your aspx/ascx code without requiring a reference to a class library.

We don't really use "includes" per se any more, but each of these tools in your toolkit allow you to provide similar concepts for different scenarios. As a developer you will interact with the entire page lifecycle of your web pages differently. ASP.NET is a very different beast than classic ASP. It truly takes a different view/approach and will take some amount of patience to figure out the differences.

BenAlabaster
Don't forget App_Code classes - which are closer to the classic ASP model than a Class Library.
Mark Brackett
Oh yes, I forgot those... thanks
BenAlabaster
A: 

How about <% Response.WriteFile("myFile.aspx) %> ?

Stuart