flera siter i en bin

det vet jag inte om det går men jag vet att det går att skapa en ny mapp och lägga hela den nya siten där.

Dud kan ha hur många dll-filer som helst i din bin-katalog.
De kan ju förståss inte heta likadant.
Men! det är ju här "återvinningen" sker, dvs om du har en generell "db-wrapper" så ska ju den oxå återfinnas i nästa projekt. Samma dll, olika projekt ......

cya,
PatrikB

Du ska heller inte ha samma namespace, klassnamn i de olika dllerna då blir det en konflikt.

Leffo skrev:

Du ska heller inte ha samma namespace, klassnamn i de olika dllerna då blir det en konflikt.

Precis, däremot kan du ha samma klassnamn om de ligger under olika namspace!

Namespace1.Klass1
Namespace2.Klass1

Kom även ihåg att *.pdb filer är debug filer och ska inte vara med på en skarp version (blir lite söligare då). För att få bort dem måste man bygga som release samt ändra i compilation taggen i web.config filen till debug= false (eller nått liknande).

*.pdb filer innehåller information som gör att en debugger från binären (.exe eller .dll) kan peka ut källkodsraden för en viss instruktion.

Grynet skrev:

...blir lite söligare då...

Nej, det stämmer inte. När programmet körs används inte pdb-filen. Den laddas endast av en debugger.

Man ska alltid generera pdb-filer även i Release builds och spara dessa. Får man allvarliga problem på en skarp site och måste felsöka där, kan man kopiera dit den undansparande pdb-filen och starta en debugger. Det går inte att i efterhand generera en pdb-fil när problem väl uppstått, det är en förebyggande åtgärd.

[redigerat]
Fattar nog inte ditt svar riktigt develop. I en release strippas .pdb filerna automatiskt ju.
[/redigerat]

Eftersom debug classen och alla breakpoints ignoreras i release builds, dvs releasen inte behöver hålla koll på (monitor) denna informationen så kommer releasen att exekviera snabbare...om det inte skulle göra detta vore det ju totalt meningslöst att ens ha dessa två options (release/debug).

I en release använder du trace objektet för att leta fel medans du enbart använder debug objektet i prereleaser.

Grynet skrev:

I en release strippas .pdb filerna automatiskt ju.

Nej, det stämmer inte. PDB-filer är inget som "strippas" (Det förekommer att man strippar pdb-filer, men det är av ett annat syfte än vad du beskriver). PDB-filer är något man väljer att generera (eller att inte generera), genom att välja "True" (eller "False") för "Generate Debugging Information" från Build-inställningarna för sitt C# projekt.

Det finns några bra artiklar, bland annat av John Robbins, speciellt denna. Sök på MSDN efter fler.

Som sagt är PDB-filer (Program Database) till för att man under debugger ska mappa binärens klasser, variabler, funkioner etc till källkodsfiler. De innehåller alltså ingen kod som körs eller liknande. PDB-filers existens (eller frånvaro) har därför ingen som helst påverkan på prestanda.

Väljer man att generera PDB-filer kommer exe-filen innehålla en sträng som pekar ut path:en till PDB-filen. Det är enda skillnaden på binären. Det finns ingen koppling mellan debug/release konfiguration och huruvida PDB-filer genereras eller inte, däremot är default-värdena olika. Default-inställningen är True för debug-konfiguration och False för release-konfiguration. Man bör dock alltid sätta True även för release-konfiguration.

Skillnader mellan debug och release konfigurationer är alls stor i C# - gå igenom alla projekt inställningar så ser du exakt alla skillnader som finns. De flesta optimeringarna görs av JIT-kompilatorn, dvs inte under genereringen av IL-koden. "Kompilerings-konstanten" (makron i C/C++) DEBUG som definieras i debug konfiguration kan man som programmerare exempelvis använda för att lägga in mer verifieringskod i sina egna program. Annars har det ingen påverkan på prestanda. Däremot spelar det förstås in hur krävande kod som endast kompileras om DEBUG är definierad, dvs anrop till System.Diagnostics.Debug.* och egen kod typ:

[Conditional("DEBUG")]
void DoExtraValidatation(string[] strings) {
    // gör saker som är långsamma och/eller som man endast vill ha
    // sina debug-versioner
}

eller

#if DEBUG
    // gör saker som är långsamma och/eller som man endast vill ha
    // sina debug-versioner
#endif

Har man mycket verifieringskod, som ju bara kommer med när DEBUG är definierad, blir det större skillnad mellan debug och release konfigurationerna. Har man ingen verifieringskod blir skillnaden förmodligen inte ens mätbar (eftersom de stora optimeringaran görs när programmet körs, inte när det kompileras från C# till MSIL).

Grynet skrev:

alla breakpoints ignoreras i release builds

Nej, det har du fått om bakfoten. Anledningen till att du inte kan sätta breakpoints är just att du inte har några symboler (PDB-filer). Hur ska debuggern veta var breakpoint-instruktionen ska läggas om du inte har en mappning mellan källkod och binär? Slå på "Generate Debugging Information" så kan du sätta breakpoints även i din release-konfiguration. Mycket användbart.

Grynet skrev:

I en release använder du trace objektet för att leta fel medans du enbart använder debug objektet i prereleaser.

Vet inte riktigt vad du menar med det. Jag använder Debug.*-metoder för all form av intern kontroll av mitt program. Sedan får kunden programmet byggt med release-konfiguration, och då finns Debug.* koden inte med. Däremot aldrig jag inte koden manuellt, utan det sköts beroende på vilken konfiguration man bygger. Antar att det var vad du menade, för du går väl knappast igenom all din kod och ändrar något innan in release?

Förlåt skrev lite otydligt med att de är strippade i en release menar jag med om man sätter debug attributet till false i compilation taggen i web.config. My bad.

Selecting the debug build option generates a program database file (.pdb) containing information about symbols used within the application when the project is compiled. Visual Studio .NET uses the program database to monitor the values of variables, set breakpoints, and evaluate Debug class members.

Selecting the release build option does not generate this file, thereby disabling Debug class members and causing breakpoints to be ignored. Because release builds don' t have to monitor this extra information, they execute faster than debug builds.

The application' s build option and Web.config setting should agree. There is no advantage in having one set to debug and the other set to release; however, Visual Studio .NET does not automatically change one when you change the other.

Från developing web applications with micrsoft visualbasic.net and microsoft visual C# .net

Antar att det var vad du menade, för du går väl knappast igenom all din kod och ändrar något innan in release?

Pesic. Och är det någon som skiter sig som man vill kolla eller ha koll på så använder jag trace objektet eftersom jag har disablat debug objektet. Trace objectet kan man ju enkelt sätta på eller av på serven med trace objectet i web.config. Utan att behöva bygga om etc. Och enligt MS (samma bok som ovan) så skall trace 'not affect performance'.

Nåja detta var inte min mening att hamna i en djup discussion om debug modes utan mer att göra folk uppmärksamma på att man kan stänga av dem för att få en prestandardhöjning om en lite så en höjning.