[VWD2005] ASP.NET kan niet online?

[Predje]

Hey Allemaal,

Ik ben weer tegen een heerlijk probleem aangelopen.
Ik maak ASP.NET pagina met Visual Web Developer Express Edition 2005.
Nu heb ik enkele pagina met een CODEBEHIND file.
Deze pagina zien er als volgt uit
tabletest.aspx

code:

<%@ Page Language="VB" AutoEventWireup="false" CodeFile="tabletest.aspx.vb" Inherits="tabletest" %>

en de codebehind tabletest.aspx.vb

code:

Imports System.Web.UI.WebControls

Partial Class tabletest
    Inherits System.Web.UI.Page

    sub gebeuren

End Class

Nu werkt die lokaal (debug) gewoon goed, maar als ik de "applicatie" naar een webserver verhuis loop ik tegen problemen aan.

code:

Server Error in '/ontwikkeling' Application.
Parser Error
Description: An error occurred during the parsing of a resource required to service this request. Please review the following specific parse error details and modify your source file appropriately.

Parser Error Message: Could not load type 'tabletest'.

Source Error:

Line 1:  <%@ Page Language="VB" AutoEventWireup="false" CodeFile="tabletest.aspx.vb" Inherits="tabletest" %>

Na veel zoeken kwam ik erachter dat een ASP.NET applicatie een BIN folder heeft en dat hierin DLL files moeten staan. Veel mensen geven aan deze te kunnen laten maken met build website.
Dit werkt niet binnen VWD2005 ook is hierin geen PUBLISH website functie te vinden.
Ik heb in mijn applicatie dus helemaal geen DLL files. IIS staat verder gewoon goed ingesteld op de server want alle andere pagina`s werken gewoon (html, css, aspx zonder codebehind).

Begrijp ik had nu goed als ik zeg dat je een website moet compileren, builden, publischen of hoe ze het ook noemen om van je aspx.vb files DLL files te maken als zijnde een CLASS voor je .aspx pagina`s?

[Verwijderd]

Bij mijn ASP.NET solution gemaakt in Visual Studio 2003 kreeg ik idd een bin directory als submap van mijn webpagina (dus bijv. \inetpub\wwwroot\website\bin). Als ik een update wilde doen, hoefde ik alleen deze dll te vervangen...

[Not Pingu]

VWD2005 werkt volgens het (verguisde en vervloekte) ASP.NET 2.0 compilatiemodel. Dat houdt in dat je source files on-the-fly gecompileerd worden naar assemblies in je Temporary ASP.NET Files map. Je hebt dan geen controle meer over de assembly waarin het komt te staan, en je kunt ook niks precompileren.

Ik denk dat je ASP.NET 2.0 code probeert te draaien op een host die ingesteld is op ASP.NET 1.1

[Predje]

Gunp01nt schreef op donderdag 09 maart 2006 @ 13:02:
VWD2005 werkt volgens het (verguisde en vervloekte) ASP.NET 2.0 compilatiemodel. Dat houdt in dat je source files on-the-fly gecompileerd worden naar assemblies in je Temporary ASP.NET Files map. Je hebt dan geen controle meer over de assembly waarin het komt te staan, en je kunt ook niks precompileren.

Ik denk dat je ASP.NET 2.0 code probeert te draaien op een host die ingesteld is op ASP.NET 1.1

10 punten voor jou!
Gister toevallig contact gehad met de provider en gezegt dat ik alleen dingen uit 1.1 gebruik.
Alles wat ik heb gelezen met DLL files enzo is dus van 1.1.
Nu draait mijn app onder 2.0 en werken de codebehind-files WEL

[Woy]

Gunp01nt schreef op donderdag 09 maart 2006 @ 13:02:
Je hebt dan geen controle meer over de assembly waarin het komt te staan, en je kunt ook niks precompileren.

Ik weet niet hoe het met de VWD werkt maar ik de gewone visual studio kun je gewoon je applicatie pre-compilen

[Not Pingu]

rwb schreef op donderdag 09 maart 2006 @ 14:14:
[...]

Ik weet niet hoe het met de VWD werkt maar ik de gewone visual studio kun je gewoon je applicatie pre-compilen

Dat kan in VWD niet.

Overigens heeft Microsoft na de ladingen kritiek op het ASP.NET 2.0 compilatiemodel een plugin uitgegeven die zgn. Web Deployment Projects toevoegt waarmee een webapp wel naar een private assembly gecompileerd kan worden.
Helaas ontbreekt de plugin-functie uit Visual Studio in de Express editions, dus is deze plugin niet beschikbaar voor VWD.

Mocht je echt perse een private assembly willen maken zonder VS2005 te moeten warezen, download dan Visual C# 2005 Express edition.
Daarmee kun je een class library maken waarin je al je source files alsnog kunt compileren. Wel even System.Web.dll toevoegen in de references.

[Predje]

Maar wat is er dan slecht aan de manier van VWD2005 i.c.m. asp.net 2.0?

Ik compileer dus eigelijk niets.. ik build de website (uitvoerige test lees ik) en upload de files aspx én aspx.vb. i.p.v mijn aspx.vb files te compilen naar .DLL`s in de bin folder.
Asp.net 2.0 compiled dat on-the-fly mijn aspx.vb files naar .dll files(?).

Snap ik het nu gewoon niet? Wat is er slecht aan? Hoe kan het beter? Wat is het beste?

[Not Pingu]

Predje schreef op donderdag 09 maart 2006 @ 15:24:
Maar wat is er dan slecht aan de manier van VWD2005 i.c.m. asp.net 2.0?

Ik compileer dus eigelijk niets.. ik build de website (uitvoerige test lees ik) en upload de files aspx én aspx.vb. i.p.v mijn aspx.vb files te compilen naar .DLL`s in de bin folder.
Asp.net 2.0 compiled dat on-the-fly mijn aspx.vb files naar .dll files(?).

Snap ik het nu gewoon niet? Wat is er slecht aan? Hoe kan het beter? Wat is het beste?

Stel ik heb een paar Custom controls gemaakt die ik over meerdere projecten wil gebruiken. Wat is dan handiger? De hele verzameling source files iedere keer naar de App_Code map kopieren, of compileren naar een DLL-etje?
Distributie van je applicatie naar derde partijen betekent in feite altijd dat je je source laat inzien. Dat wil je niet altijd, bijv. als je als bedrijf gewoon niet kiest voor de open source methode. Nou zijn .NET libraries erg makkelijk te disassemblen, maar dat terzijde.

Ook het meecompileren van resources in een assembly is niet meer mogelijk, bijv. voor NHibernate.

En sowieso biedt het opzich geen voordeel om iets on-the-fly te laten compileren, behalve in het geval van debuggen (als je 1 pagina aanpast wordt alleen die gehercompileerd en niet je applicatie). In een live-omgeving heb je er niks meer aan en is die extra warmup-time alleen mar hinderlijk.

[cowgirl]

Gunp01nt schreef op donderdag 09 maart 2006 @ 15:41:
Stel ik heb een paar Custom controls gemaakt die ik over meerdere projecten wil gebruiken. Wat is dan handiger? De hele verzameling source files iedere keer naar de App_Code map kopieren, of compileren naar een DLL-etje?

Custom controls zijn volgens mij altijd class-library projecten en daarmee altijd dll's. Deze kan je dan gewoon vanuit een web-project referencen.

Voor Visual Studio is er ook een complete template voor web applicatie projecten, zie http://webproject.scottgu.com/