[C#, ASP.NET] Compileren vanuit web.config

[jobo]

Hallo,

Ik heb een webapplicatie met daarin een klasse (consts.cs) die verantwoordelijk is voor allerlei constante variabelen. Wanneer ik hierin een wijziging aanbreng (bijvoorbeeld een locatie van images) dan wordt deze niet meegenomen in de applicatie omdat de webserver de code niet opnieuw compileerd. Nu heb ik zo'n dikke ASP.NET bijbel, waarin een stukje staat over compiler functionaliteiten in de web.config file van je project. Echter na het toevoegen van deze regels, werkt het nog niet.

Heeft iemand iedeeën hoe ik iedere keer dat een applactie gestart wordt de code opnieuw kan compileren?

[Daspeed]

Is er een reden waarom je die 'constante variabelen' niet in een config file zet, zodat je ze kunt aanpassen zonder opnieuw te hoeven compilen?

[cannibal]

Mij lijkt de web.config of de machine.config ook de aangewezen plek voor deze variabelen.

Maar welke regels heb je toegevoegd.
Beetje meer informatie lijkt me gewenst.

[jobo]

code:

<configuration>
<system.web>
<complilation debuf="false" explicit="true" defaultLanguage="c#">
<compilers>
<compiler language="c#;cs;csharp;" extension=".cs" type="Microsoft.CSharp.CSharpCodeProvider, System"/>
</compilers>
</compilation>
</system.web>
</configuration>

[cannibal]

Als dat copy-paste is lijkt me er al een fout in te zitten.
debuf="false" zal wel debug="false" moeten zijn.

Gebruik je trouwens .Net framework 1.1 of 2.0?

[ Voor 28% gewijzigd door cannibal op 21-06-2006 14:54 ]

[dotcode]

constante variabelen bestaan volgens mij niet.

Je hebt constanten en variablen. Constanten zijn altijd het zelfde, variablen kunnen veranderen.

Als ik je probleem lees zou je het met de web.config moeten oplossen. Als je daarin je variable veranderd zal je web applicatie vanzelf opnieuw starten en de nieuwe variable oppakken. Mooier is het om het in een DB te zetten zodat je niet elke keer als je iets verandert je webapp opnieuw moet starten dat vrij traag is.

[jobo]

Was geen copy paste werk.

Ik ben uiteraard gewoon aan het proberen een oplossing voor dit probleem te vinden. Tikte net de code over uit het boek dat ik heb gebruikt. dit werkt dus niet, want ik krijg een melding dat System niet gevonden kan worden. Je kunt hier dan een assembly aan toevoegen, maar dan wordt de foutmelding daarop gegeven.

code:

<compilation>
  <assemblies>
    <add assembly="System"/>
  </assemblies>
</compilation>

De reden waarom ik dit in een .cs file heb gepropt is dat ik nog geen tijd heb gehad om bijvoorbeeld een XML interface te maken waarmee de instellingen te beheren zijn door de klant. je wilt natuurlijk niet dat een klant in de web.config moet gaan zitten snuffelen, tussen de instellingen van je webapplicatie om ergens een naam van een database of zoekveld aan te passen.

[ Voor 34% gewijzigd door jobo op 21-06-2006 14:58 ]

[cannibal]

Als je een DB gebruikt, moet je eigenlijk ook al weer een pagina maken waarin je deze waarden kunt wijzigen. "Hacken" in de database is in productie omgevingen natuurlijk ook "not-done".

Maar als 'constanten' vaak wijzigen heb je natuurlijk gelijk.
Beetje afhankelijk van de frequentie van wijzigen.

[jobo]

De constanten zullen per klant opgegeven worden. Mijn applicatie zal straks in enkele landen gebruikt worden. dus zit er een mogelijk in om de namen van weergegeven velden (captions) aan te passen aan de taal van dat land. De database naam kan anders zijn, aangezien ieder land zijn eigen database heeft. De zoekvelden binnen de database moeten instelbaar zijn, omdat de applicatie wellicht voor verschillende klanten gebruikt moet gaan worden.

Een mooie uitbreiding zou zijn dat ik een webform maak waarmee door een beheerder de instellingen gewijzigd kunnen worden, maar daar ben ik nog niet aan toegekomen en dat terwijl ik wel het een en ander moet opleveren zodat er getest kan worden.

[cannibal]

Maar als je per klant een eigen instantie hebt van de site / applicatie.
Kun je al die gegevens (constanten) en database connectionstring naar mijn mening gewoon het makkelijkste in de web.config zetten.

System.Configuration.AppSettings opzoeken in de msdn.
Daar kun je volgens mij wel mee vooruit.

[jobo]

Maar ik laat de klant toch geen wijzigingen in de web.config uitvoeren! Daar zitten immers ook de instellingen met betrekking tot debugging, login mechanisme, encoding van data, session of cookies in. dat kan ik niet maken. de kans dat een klant de applicatie vernachelt, omdat er een verkeerder instelling is verandert wordt dan wel heel erg groot...

zijn er geen andere mogelijkheden zoals ik die als eerste beschreef? dat moet toch ook gewoon kunnen werken? ze geven het tenminste wel in het boek aan. Het werkt dus alleen niet bij mij.

suggesties???

[bigbeng]

jobo schreef op woensdag 21 juni 2006 @ 15:12:
Maar ik laat de klant toch geen wijzigingen in de web.config uitvoeren! Daar zitten immers ook de instellingen met betrekking tot debugging, login mechanisme, encoding van data, session of cookies in. dat kan ik niet maken. de kans dat een klant de applicatie vernachelt, omdat er een verkeerder instelling is verandert wordt dan wel heel erg groot...

zijn er geen andere mogelijkheden zoals ik die als eerste beschreef? dat moet toch ook gewoon kunnen werken? ze geven het tenminste wel in het boek aan. Het werkt dus alleen niet bij mij.

suggesties???

En dit gaat niet op voor een cs file die gecompileerd moet worden? Alles wat daarvan gebruik maakt gaat toch ook op zn plaat? Schrijf dan zelf een configuratiebestand dat je op een standaardmanier inleest.

[jobo]

cannibal74 schreef op woensdag 21 juni 2006 @ 14:52:
Gebruik je trouwens .Net framework 1.1 of 2.0?

Ik gebruik versie 1.1

[mulder]

Alles behalve de connectiestring kan alles gewoon in database of gewoon bestandje, registry whatever?

[jobo]

Dat het kan weet ik, maar nu zit het dus in een .cs bestand. Daarin heb ik bij elkaar ongeveer 40 regels staan die eruit zien als hieronder

code:

public static string DEFAULT_<Constantenaam> = <waarde>

nu kun je vanuit je programmacode een import doen van de cs file en daarna in je methoden bijvoorbeeld Consts.DEFAULT_<Constantenaam> doen waarmee de applicatie de waarde ophaalt.

Wanneer ik nu dus de waarde wijzig terwij de applicatie al op IIS draait, dan wordt deze wijziging niet meegenomen in de applicatie wanneer ik deze opstart vanaf een clientmachine of de server zelf (met internet explorer) Wanneer ik dit op de ontwikkel omgeving doe, dan ram ik op F5 om de applicatie te runnen in debugmode, maar dan worde code ook gecompileerd. dan werkt het wel. Dit is uiteraard niet te doen door de klant zelf omdat deze niet de beschikking heeft over een ontwikkelomgeving.

[Sybr_E-N]

Als je applicatie meerdere talen moet kunnen ondersteunen kom je al snel in de hoek van Globalization en Localization. Die functionaliteit zit al standaard in .NET gebakken en hoef je ook niet moeilijk te doen met een extra database voor dat soort dingen.

[jobo]

Dat snap ik ook allemaal wel, maar het is wel veel werk om nu nog een dergelijke database of xml interface (zoals de klant het wil hebben) te maken voor de opleverdatum.

Is er dus geen mogelijkheid om het .Net framework te laten compileren bij het starten van de applicatie?
dan moet ik een andere oplossing gaan verzinnen. Dan kan de klant gaan testen met alle gegevens zoals hij deze wenst te hebben. Dan vermeld ik erbij dat de module voor het wijzigen er aan komt. ik heb dan weer enkele weken tot de volgende opleverdatum...

ik hoor graag van jullie.

[ Voor 23% gewijzigd door jobo op 21-06-2006 15:35 ]

[gorgi_19]

Wat is er mis met een .config bestandje met een Cachedependency?

Realtime compilen kan trouwens wel met CodeDom namespaces, maar echt vrolijk wordt je daar niet van.

Is er dus geen mogelijkheid om het .Net framework te laten compileren bij het starten van de applicatie?

Ja, maar dat kost een sloot aan code en performance.

[ Voor 35% gewijzigd door gorgi_19 op 21-06-2006 15:36 ]

[bigbeng]

Op een server zal in principe geen .NET SDK geinstalleerd zijn, alleen het Framework. Dat betekent dat de compiler dus ook ontbreekt. . Normaalgesproken heb je op je .NET webapplicatie alleen de ASPX files staan en staat de gecompileerde code als dll in de bin directory.

Wat je kunt doen (en dit kan volgens mij vrij eenvoudig) is al je constanten en hun waarden opnemen in de web.config:

code:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
... standaard geneuzel...

 <appSettings>
   <add
       key="<ConstanteNaam>"
       value="<Waarde>"
     />
... etc...
 </appSettings>

</configuration>

Vervolgens herschrijf je je consts.cs en doe je het volgende:

C#:

public static string DEFAULT_<Constantenaam> = System.Configuration.ConfigurationSettings.AppSettings["<Constantenaam>"];

edit:

onzin geklets ff doorgehaald

[ Voor 13% gewijzigd door bigbeng op 21-06-2006 15:47 ]

[ZeroCode]

bigbeng schreef op woensdag 21 juni 2006 @ 15:45:
Op een server zal in principe geen .NET SDK geinstalleerd zijn, alleen het Framework. Dat betekent dat de compiler dus ook ontbreekt. . Normaalgesproken heb je op je .NET webapplicatie alleen de ASPX files staan en staat de gecompileerde code als dll in de bin directory.

Wat je kunt doen (en dit kan volgens mij vrij eenvoudig) is al je constanten en hun waarden opnemen in de web.config:

code:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
... standaard geneuzel...

 <appSettings>
   <add
       key="<ConstanteNaam>"
       value="<Waarde>"
     />
... etc...
 </appSettings>

</configuration>

Vervolgens herschrijf je je consts.cs en doe je het volgende:

C#:

public static string DEFAULT_<Constantenaam> = System.Configuration.ConfigurationSettings.AppSettings["<Constantenaam>"];

edit:

onzin geklets ff doorgehaald

wat hij dus elke keer aangeeft is dat de klant de web.config kan veranderen. Dat wil hij dus niet.
Hij wil gewoon dat de applicatie opnieuw 1malig gecompileerd word na een wijziging en dit wil hij oplossen in de web.config door dit:

code:

<configuration>
<system.web>
<complilation debug="false" explicit="true" defaultLanguage="c#">
<compilers>
<compiler language="c#;cs;csharp;" extension=".cs" type="Microsoft.CSharp.CSharpCodeProvider, System"/>
</compilers>
</compilation>
</system.web>
</configuration>

de vraag is dus of dat mogelijk is en hoe

[gorgi_19]

nee, vanaf .Net 2.0 heb je die mogelijkheid pas.

[cannibal]

Maar goed in kader van de applicatie mollen maakt web.config of een const.cs niets uit.
web.config krijg je nog een redelijke melding van, maar van een niet compilerend bestand, hmm, daar durf ik de consequenties zo niet allemaal van te noemen.
Vooral ook dat mensen dat complete applicatie code kunnen toevoegen. Wat mij gevaarlijker lijkt als het slopen van een web.config (die je een als een .default iig altijd nog reserve kunt meegeven)

[jobo]

gorgi_19 schreef op woensdag 21 juni 2006 @ 16:05:
nee, vanaf .Net 2.0 heb je die mogelijkheid pas.

Hoe kan het dan in een boek staan van ASP.NET 1.1

cannibal74 schreef op woensdag 21 juni 2006 @ 16:06:
Maar goed in kader van de applicatie mollen maakt web.config of een const.cs niets uit.
web.config krijg je nog een redelijke melding van, maar van een niet compilerend bestand, hmm, daar durf ik de consequenties zo niet allemaal van te noemen.
Vooral ook dat mensen dat complete applicatie code kunnen toevoegen. Wat mij gevaarlijker lijkt als het slopen van een web.config (die je een als een .default iig altijd nog reserve kunt meegeven)

Ik wil niet dat de klant de web.config kan veranderen omdat daar login instellingen en dergelijke in staan (zoals eerder aangegeven) Ik snap allemaal wel dat het daarin heel goed kan, maar daar schiet de klant nu niets mee op.

Ik ga wel een andere oplossing bedenken. niet handig, maar kan nu ff niet anders. Vraag hem exact hoe de instellingen moeten zijn. ik comileer met die instellingen het programma en kopieer die naar de server. wordt even stoeien met een memory sticky, maar tis nu niet anders.

Mochten er nog mensen zijn die de mogelijkheden om toch te compileren (zoals in het boek beschreven staat) werkend hebben, dan hoor ik het wel.

[ Voor 75% gewijzigd door jobo op 21-06-2006 16:15 ]

[bigbeng]

ZeroCode schreef op woensdag 21 juni 2006 @ 16:02:
[...]
wat hij dus elke keer aangeeft is dat de klant de web.config kan veranderen. Dat wil hij dus niet.
...

Ik heb dat ook wel gelezen, maar het is een BS argument. Als de klant in een .cs file (die zeer waarschijnlijk een x aantal directories dieper staat dan de web.config) kan (en blijkbaar mag) aanpassen en potentieel vernaggelen, dan kan hij dat vast ook wel met de web.config, die komt ie onderweg naar de cs toch tegen. Ik bood mijn stuk code aan als een snel alternatief.

Een beter (en verder uitgedacht) alternatief is dat je met System.Configuration en XMLReader een eigen configuratiebestandlezer maakt. Ik heb daar nog wel voorbeelden van, dus de TS (en andere gegadigden ) kunnen mijn profile raadplegen en me ff een mailtje sturen. Als je lief genoeg bent stuur ik je misschien de code wel

Edit:
Ik onderstreep overigens het berichtje van Sybr_E-N dat het beter is om van resource files gebruik te maken voor taal en regio afhankelijke zaken. Maar dit terzijde.

[ Voor 9% gewijzigd door bigbeng op 21-06-2006 16:25 ]