[.Net Linq] Datacontext null reference exception

[L01]

Ik maak gebruik van LINQ to SQL om te “praten” met mijn database.

Ik heb een class aangemaakt die wat parameters ontvangt en die in opslaat in de database. Dit werkt prima als ik deze class aanroep via de code-behind van een aspx pagina. Echter, deze class moet aangroepen worden vanuit een thread. Wanneer ik dat doe krijg ik een null-reference exception op het aanmaken van de System.Data.Linq.DataContext.

Dit doe ik op de volgende manier:

C#:

NotificationDataClassDataContext db = new NotificationDataClassDataContext();

Nu lijkt het zo te zijn dat het dus wel werkt als ik deze class aanroep via een aspx pagina maar niet via een thread. Ik heb al een tijdje rondgezocht en ik heb werkelijk geen idee hoe ik dit moet oplossen, heeft iemand een suggestie?

[EfBe]

Tja, zonder stacktrace wordt het onmogelijk er ook maar iets over te zeggen. Een exception zonder stacktrace is als bier zonder kraag.

[ Voor 20% gewijzigd door EfBe op 17-06-2008 17:33 ]

[Tim]

Uit MSDN:

Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.

Misschien is dat het probleem?

[L01]

Ik heb nog een tijdje zitten debuggen en wat blijkt: de web.config kan niet worden uitgelezen... Daar zit een connection string in die de DataContex moet gebruiken.

Hoe kan dit , en misschien nog belangrijker: hoe los ik dit op?

[TeeDee]

En waarom kan de web.config niet uitgelezen worden? Dat lijkt me namelijk een redelijk essentieel onderdeel van .Net.

Over welke/wat voor thread (wat imo nog steeds vrij nutteloos is in een web project) hebben we het?
Staat System.Configuration in je using declaratie?

[ Voor 40% gewijzigd door TeeDee op 18-06-2008 11:36 ]

[L01]

De thread wordt aangemaakt om periodiek gegevens in de database te controleren. Deze thread stuurt gegevens naar een appart project, welke deze gegevens verwerkt.

Het lijkt erop dat wanneer ik deze module aanspreek vanuit een thread dat verschillende dingen niet werken zoals het uitlezen van de web.config of het verkrijgen van de windows login informatie...

Het gaat om System.Threading en voor de rest is de code gewoon goed aangezien het wel werkt als ik de class aanroep vanuit een aspx pagina.

[ Voor 16% gewijzigd door L01 op 18-06-2008 13:20 ]

[bigbeng]

Haalt dit aparte project de configuratiegegevens op? Of krijgt hij die in de vorm van parameters of properties mee? Wat voor soort project is het?

[L01]

Het hoofdproject is een vb.net webapplicatie waarbij de business logic in een VB.net applicatie zit.
Vanuit die VB.net applicatie wordt mijn c# web applicatie aangeroepen.

[bigbeng]

Applicatie als in executable? Ik meen me te herinneren dat een exe zijn eigen appdomain krijgt en dus ook zijn eigen .config file.

[L01]

nee, het is een class library (dus met een app.config)

[ Voor 30% gewijzigd door L01 op 18-06-2008 14:25 ]

[bigbeng]

Okee, noem me sloom, maar ik volg het niet helemaal. Je hebt dus een VB.Net web applicatie, een C#.Net web applicatie en een VB.Net class library? Waarom 2 webapps? En tenzij dit veranderd is met visual studio 2008.Net 3.0/3.5, maar een class lib gebruikt normaal gesproken de config van de aanroepende executable (web app of .exe). Dus de dll heeft geen eigen config file.

[L01]

Ik weet niet of ik het helemaal goed doe, dit is de eerste keer dat ik met .NET werk maar ik probeer dus een bepaalde functionaliteit (het verzenden van notificaties) buiten de hoofd applicatie te laten. Zo kunnen meerdere applicaties gebruik maken van deze "module".

Ik wil ook de gegevens die ik in de module creer weergeven op een web pagina, vandaar dat ik gekozen heb voor een web applicatie...

Blijkbaar is dit geen goed idee?

[bigbeng]

1 webapp is een uitstekend idee, maar de vraag is waarom 2?

[L01]

Ik heb besloten om te kijken of het wel werkt als ik een ander soort project gebruik. De class library valt onder "windows" als ik een nieuw project aanmaak, onder web kan ik zoiets niet vinden.

Kan ik gewoon een class library gebruiken of moet ik een ander soort type gebruiken?

[bigbeng]

Business Logic in een class library en de visualisatie in een webapplicatie lijkt mij een goede manier van werken.

[D-Raven]

bigbeng schreef op woensdag 18 juni 2008 @ 14:38:
Okee, noem me sloom, maar ik volg het niet helemaal. Je hebt dus een VB.Net web applicatie, een C#.Net web applicatie en een VB.Net class library? Waarom 2 webapps? En tenzij dit veranderd is met visual studio 2008.Net 3.0/3.5, maar een class lib gebruikt normaal gesproken de config van de aanroepende executable (web app of .exe). Dus de dll heeft geen eigen config file.

Dat is niet waar. Een dll kan gewoon zijn eigen app.config hebben. En hij heeft zeker niet toegang tot de config file van de aanroepende dll/exe. Als jij settings uit de de aanroepende library wilt aanroepen via de "standaard" manier. Dus via Properties.Settings etc. Dit is dan de Properties.Settings uit de aanroepende library. Waardoor je dus een reference creëert naar deze library. Pas dan heb je toegang tot de config file van een andere exe/dll. Alternatief kun je ook gewoon het absolute pad opgeven en direct het bestand uitlezen. Maar automagisch gebeurd het dus niet.

(edit: even benadrukt dat ik het over de settings uit een app.config heb)

Hoe LINQ en dergelijke hiermee om gaat weet ik niet. Nog niet veel met LINQ gedaan, maar kan me voorstellen dat je bij het instantieren van je context een configuratie moet meegeven. Indien je niks meegeeft zou het kunnen dat hij de app.config van je huidige thread probeert op te halen.
Dit zou verklaren waarom het direct vanuit een aspx wel werkt en vanuit een eigen thread niet.

@L01

Klinkt alsof je meer een service applicatie wilt hebben welke een interface aanbied naar de buitenwereld waar andere programma's weer tegen aan kunnen praten.
Dan is die notificatie module dus een autonoom iets, wat gewoon ergens draait en wacht todat het wordt aangeroepen. Is dat soms wat je wilt?

Of bedoel je meer dat je je notificatie module als een aparte dll wilt opnemen waar gewoon een aantal klasses inzitten die je instaat stellen om notificaties te sturen en dergelijke.
Als je dat doet dan moet je wel bedenken dat een dll niet op zichzelf leeft. Een dll draait niet in zijn eigen app domein. Een dll draait in de app domain van de exe of webapplicatie die hem aanroept.
Dus als jij in je webapp die dll gebruikt om notificaties klaar te zetten. Dan zal een andere applicatie die ook die dll gebruikt geen toegang/notie hebben van die dingen die je webapp heeft gedaan.

Dus als jij je notificatie module meer als een aparte applicatie ziet dan moet je een service bouwen.
Maar als je het meer ziet als een verzameling code welke door verschillende applicaties gebruikt kan worden dan kun je er een dll van maken.

Hoop dat t n beetje duidelijk is..:)

[TeeDee]

Je kan je Class library los van je web-, windows of wat dan ook aanmaken. Dat moet niets uitmaken. Je zal 'm alleen wel moeten referencen in bijv. je web applicatie. Tevens zal je iets moeten verzinnen op het .config 'probleem'. Dit kan je simpel doen door in de Class library iets doen als ConfigurationManager.Appsettings (of ConnectionStrings) hardcoded in te lezen. Wil je het helemaal netjes doen kan je kijken naar een eigen Configuration implementatie.

[L01]

Klinkt alsof je meer een service applicatie wilt hebben welke een interface aanbied naar de buitenwereld waar andere programma's weer tegen aan kunnen praten.
Dan is die notificatie module dus een autonoom iets, wat gewoon ergens draait en wacht todat het wordt aangeroepen. Is dat soms wat je wilt?

Klopt, dat is precies wat ik aan het maken ben maar de "main" applicatie maakt gebruik van Objecten in deze module. Daarom heb ik het in dezelfde solution zitten.

Waarschijnlijk wordt het dus een DLL. Ik ga kijken wat er gebeurd als ik een class library maak.

[D-Raven]

Waarom maak je dan niet een model/shared dll waarin de gedeelde klasses zitten, en een notification service welke als application draait. Dan kan je main applicatie gewoon je notificatie service aanroepen zonder dat het de service direct referenced.

[bigbeng]

D-Raven schreef op donderdag 19 juni 2008 @ 09:39:
[...]


Dat is niet waar. Een dll kan gewoon zijn eigen app.config hebben. En hij heeft zeker niet toegang tot de config file van de aanroepende dll/exe. Als jij settings uit de de aanroepende library wilt aanroepen via de "standaard" manier. Dus via Properties.Settings etc.
[knip]

Ik redeneerde vanuit ConfigurationManager.ConnectionStrings. En deze kun je voor zover ik weet alleen manipuleren door een nieuw appdomain in te stellen.
En voor zover ik kan zien worden de application settings hard ingebakken in je assembly. En is daarmee dus niet meer flexibel configureerbaar.

[D-Raven]

Dat van de connectionstrings weet ik niet. Maar volgens mij gebruikt hij achter de schermen daar ook GetSection voor.
M.b.t de settings wordt er een soort designer file voor je gecreeerd zodat je je settings direct kunt aanspreken, dit is wat wordt ingebakken in de assembly. Maar de waarde van de settings zijn wel degelijk configureerbaar, deze worden immers nog steeds tijdens runtime uitgelezen uit je config file.

Je moet wel opletten met user settings en application settings. Als je runtime user settings aanpast dan worden deze onder local settings van de ingelogd windows user opgeslagen.
Application settings doen dat niet, maar deze kun je dan ook niet tijdens runtime wijzigen. Je kunt natuurlijk wel de application settings in de config file aanpassen en je app restarten.

[bigbeng]

Ik heb dit net getest en de setting waarde komt direct uit de assembly. Ik heb het over een class library hier, die ik combineer met een webapp. In de bin folder van de webapp komt geen config file te staan voor de dll. Als ik die wel neerzet (<assembly>.dll.config), dan wordt nog de nieuwe waarde in de config file niet gebruikt.

Als ik vervolgens de assembly open (met wordpad), dan zie ik de waarde voor mijn application setting gewoon keihard in de dll staan.

Maar goed, ik neem aan dat jij uit ervaring spreekt. Zou je kunnen uitleggen hoe ik de waarde van de setting kan wijzigen zonder hercompilatie?

[L01]

Ik heb mijn classes nu in een class library gegooid en wonderbaarlijk, de app.config kan gewoon uitgelezen worden.
Nog niet alles werkt perfect want ik benader mijn database met Windows authentification, blijkbaar kan dat niet worden gevonden want ik krijg een error zoals:

code:

Login failed for user ''

Dit heb ik nu opgelost door in de connectionString een username en password mee te geven.

[D-Raven]

bigbeng schreef op donderdag 19 juni 2008 @ 15:14:
Ik heb dit net getest en de setting waarde komt direct uit de assembly. Ik heb het over een class library hier, die ik combineer met een webapp. In de bin folder van de webapp komt geen config file te staan voor de dll. Als ik die wel neerzet (<assembly>.dll.config), dan wordt nog de nieuwe waarde in de config file niet gebruikt.

Als ik vervolgens de assembly open (met wordpad), dan zie ik de waarde voor mijn application setting gewoon keihard in de dll staan.

Maar goed, ik neem aan dat jij uit ervaring spreekt. Zou je kunnen uitleggen hoe ik de waarde van de setting kan wijzigen zonder hercompilatie?

Je moet bij de eigenschappen van de web.config Build Action --> Copy to output directory instellen
Doe je dit niet dan wordt de web.config opgenomen in je dll en werkt het niet

Ter referentie ik roep de setting als volgt aan:

C#:

using HelloWorld.Properties;

namespace HelloWorld
{
    public partial class _Default : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            Label1.Text = Settings.Default.TestSetting;
        }
    }
}

Als ik nu naar mijn url ga (localhost/<virtualDirNaam>/Default.aspx krijg ik mooi de waarde van mijn setting te zien. Verander ik nu in de web.config de waarde en roep ik de pagina opnieuw op dan is de verandering zichtbaar.

[bigbeng]

Over langs elkaar heen communiceren gesproken. Jij bedoelt dat je een eigen config-sectie kunt opnemen in je web.config voor een assembly die je referenced. Dat is wel wat anders dan dat een assembly zijn eigen config file kan hebben.

@TS: goed dat het werkt

[D-Raven]

Om te beginnen werkt het met applicaties gehost in IIS net iets anders. Maar neej, dat is niet wat ik bedoel. Het Properties.Settings.Default object leest de informatie van de dll/exe waarin het zich bevindt. (dit is de klasse welke gegenereert wordt)

Dus als jij een TestApp.Properties.Settings.Default aanroept zul jij de settings in TestApp.exe.config aanspreken.
Maar spreek jij RefDll.Properties.Settings.Default aanroepen dan zul jij de settings in RefDll.dll.config aanspreken.

Ik heb hier een windows applicatie met meerdere dll's die gereferenced worden. Een aantal daarvan hebben hun eigen app.config, welke gewoon wordt uitgelezen door de desbetreffende dll's.

Maar we raken nu wel _heel_ erg off topic , misschien is het handiger om via DM door te gaan in plaats van de TS zijn topic te kapen ?

@TS: idd goed dat je probleem is opgelost

[bigbeng]

offtopic:
Goed, stuur maar een DM, dan gaan we nog even op die manier door. Ik kan jou geen DM sturen...