C# Discussion Boards - CodeProject

Re: Production release: Do I issue a "Release" build or do I simply not copy over the debug's pdb file?

17-May-10 5:28

I'm not convinced; I can debug without a PDB file. I believe the debug symbols get built into the EXE.

The Man from U.N.C.L.E.17-May-10 5:38

Re: Production release: Do I issue a "Release" build or do I simply not copy over the debug's pdb file?

17-May-10 5:38

You may be able to debug, but you won't get any line numbers without the PDB.

If you have knowledge, let others light their candles at it.
Margaret Fuller (1810 - 1850)
[My Articles] [My Website]

PIEBALDconsult17-May-10 5:42

Re: Production release: Do I issue a "Release" build or do I simply not copy over the debug's pdb file?

17-May-10 5:42

Then how does the debugger highlight the appropriate line?

The Man from U.N.C.L.E.17-May-10 7:07

Re: Production release: Do I issue a "Release" build or do I simply not copy over the debug's pdb file?

17-May-10 7:07

ASP.NET is a cheaky little oik.

Just did some testing.

For a true release build you set to release configuration, which builds with optimisations on, debug symbols off, pdb files excluded, and DO NOT DEPLOY THE SOURCE FILES.

That last bit is the key.

You can debug if either of the following are true:

1. You deployed the source files.
2. You build using GeneratePDB-Only, or Full Debug symbols, and optimisations off

You get line numbers in your stack trace if either the PDB files, or the source files are present regardless of optimisations and debug symbol inclusion. If you do not have the PDB files, or the source files you cannot get the line numbers.

NB// For Windows applications (it is a bit clearer as you cannot deploy the source code.)

If you have knowledge, let others light their candles at it.
Margaret Fuller (1810 - 1850)
[My Articles] [My Website]

J4amieC17-May-10 5:48

J4amieC

17-May-10 5:48

No, they don't. More likely VS is being smart enough to locate them under the hood.
More info here[^]

Re: Production release: Do I issue a "Release" build or do I simply not copy over the debug's pdb file?

PIEBALDconsult17-May-10 6:01

Re: Production release: Do I issue a "Release" build or do I simply not copy over the debug's pdb file?

17-May-10 6:01

That doesn't say much; certainly nothing I didn't already know.

Eddy Vluggen17-May-10 5:49

Eddy Vluggen

17-May-10 5:49

PIEBALDconsult wrote:
I can debug without a PDB file. I believe the debug symbols get built into the EXE.

"Debugging" is a broad concept. It resembles[^] Delphi's map-file somewhat.

That doesn't mean that you can't debug without the file; if you have the original source, then I'll assume that it will generate a exact duplicate of the executable that's deployed. A better strategy would be to store everything in SourceSafe - disk space is cheap anyway.

I are Troll Suspicious | :suss:

Re: Production release: Do I issue a "Release" build or do I simply not copy over the debug's pdb file?

Alaric_17-May-10 5:56

Alaric_

17-May-10 5:56

Eddy Vluggen wrote:
A better strategy would be to store everything in SourceSafe

...you mean TFS, right? Wink | ;)

"I need build Skynet. Plz send code"

Re: Production release: Do I issue a "Release" build or do I simply not copy over the debug's pdb file?

Eddy Vluggen17-May-10 6:04

Eddy Vluggen

17-May-10 6:04

Alaric_ wrote:
...you mean TFS, right?

Floppy disk, and store it under a mattress Cool | :cool:

I are Troll Suspicious | :suss:

Re: Production release: Do I issue a "Release" build or do I simply not copy over the debug's pdb file?

PIEBALDconsult17-May-10 6:07

Re: Production release: Do I issue a "Release" build or do I simply not copy over the debug's pdb file?

17-May-10 6:07

Eddy Vluggen wrote:
store it under a mattress

Nah, the princess I'm married to would complain about the lump. Roll eyes | :rolleyes:

Giorgi Dalakishvili17-May-10 8:50

Giorgi Dalakishvili

17-May-10 8:50

Here is a really good article about PDB files: PDB Files: What Every Developer Must Know[^]

Giorgi Dalakishvili

#region signature
My Articles

Browsing xkcd in a windows 7 way[^]

#endregion

Re: Production release: Do I issue a "Release" build or do I simply not copy over the debug's pdb file?

PIEBALDconsult17-May-10 9:24

Re: Production release: Do I issue a "Release" build or do I simply not copy over the debug's pdb file?

17-May-10 9:24

That was far better information than I've seen otherwise. Thanks.

"debugging binaries you build locally is easy"

That's the only kind I have ever needed to do (so far).

Giorgi Dalakishvili17-May-10 9:29

Giorgi Dalakishvili

17-May-10 9:29

You are welcome Smile | :)

Giorgi Dalakishvili

#region signature
My Articles

Browsing xkcd in a windows 7 way[^]

#endregion

Re: Production release: Do I issue a "Release" build or do I simply not copy over the debug's pdb file?

The Man from U.N.C.L.E.17-May-10 4:07

Re: Production release: Do I issue a "Release" build or do I simply not copy over the debug's pdb file?

17-May-10 4:07

1) Absolutely. Release configuration is designed of producing public releases. However this should be part of your build process (team system/nant or whatever) and not a manual process changing each project.

2) No. Debug builds are different. For starters they define the debug symbol, so any code enclosed in the #IF DEBUG ... #ENDIF tags will run in the wild, where it definitely should not go. Also additional debug symbols will be compiled into the application in Debug, causing a larger file.

3) Check the settings for any project, and you will see that you can set a number of different compiler options for each configuration, ranging from generation of XML documentation files to enabling compiler optimisations and targeting specific CPUs. For a debug build you may not care about CPUs if the dev environment is all 32bit, but in production you have to get specific or suffer the consequences.

4) A 'True' release build, should not be debugable, will not include debug symbols, will probably not include documentation, will be optimised, does not define the TRACE or DEBUG compiler constants thereby enabling different code paths, should generate a smaller dll of exe.

PDB files should be generated in Release builds, but probably not shipped. They hold source code line number information and are therefore needed for pinpointing the line numbers where exceptions are thrown.

If you have knowledge, let others light their candles at it.
Margaret Fuller (1810 - 1850)
[My Articles] [My Website]

Alaric_17-May-10 4:48

Alaric_

17-May-10 4:48

So, if you have no code enclosed within a #IF DEBUG #ENDIF block, and you set <compilation debug="false"> inside the web.config (which would prevent insertion of debug symbols), would there still be tangible advantages to issuing under a "Release" configuration? (I just tested and my dll is 96kb whether I am in Debug or Release mode...even with the "Optimize Code" flag set)

...There should be a "Run slow" checkbox that cannot be unchecked lol.

The Man from U.N.C.L.E. wrote:
3)For a debug build you may not care about CPUs if the dev environment is all 32bit, but in production you have to get specific or suffer the consequences.

Would you care to enumerate the consequences? Even if the prod processors are 64-bit, they'd still have to be running an x64 OS for there to be any problems, right?

"I need build Skynet. Plz send code"

Re: Production release: Do I issue a "Release" build or do I simply not copy over the debug's pdb file?

Alaric_17-May-10 4:55

Alaric_

17-May-10 4:55

...and even then, that's slightly puzzling because the x86-64 extension is fully backwards compatible with the legacy x86's 32-bit instruction set. Why would there be consequences to targetting an x86 even if it were running on an x64 processor?

Or are you inferring the converse? Since a target of "Any CPU" runs on the 64 bit CLR, are you implying that if you have x86 hardware, you need to specifically target it???

"I need build Skynet. Plz send code"

Re: Production release: Do I issue a "Release" build or do I simply not copy over the debug's pdb file?

The Man from U.N.C.L.E.17-May-10 5:37

Re: Production release: Do I issue a "Release" build or do I simply not copy over the debug's pdb file?

17-May-10 5:37

Targeting x86 running on x64 requires you to change the enable32BitAppOnWin64 setting on the AppPool to true. So one possible problem there.
Targeting AnyCPU when you have a third party dll built for 32-bit will crash if the server os is upgraded to 64-bit.

So if there is any possibility of deploying on 64-bit then make sure you target x86 or x64 and not any-cpu, unless you are absolutely certain it will run under both.

If you are only deploying on 32-bit os then that setting is irrelevant.

If you have knowledge, let others light their candles at it.
Margaret Fuller (1810 - 1850)
[My Articles] [My Website]

The Man from U.N.C.L.E.17-May-10 5:30

Using Standalone SMTP email server

17-May-10 5:30

Correct on the 64-bit.

We had an instance recently where we had not set for 32-bit and referenced a 32-bit third party dll. One client upgraded without telling us, until it all died. In practive we set that for debug as well, so not a debug/release issue as such, just to take more care when setting up a release build.

If you have knowledge, let others light their candles at it.
Margaret Fuller (1810 - 1850)
[My Articles] [My Website]

msj4u17-May-10 3:31

msj4u

17-May-10 3:31

Hi,

I want to send the email from my standalone desktop application.

I searched for a stand alone email server but got only

http://www.ericdaugherty.com/dev/cses/

Actually I want to do some thing like

<br />
<br />
private void mailNow()<br />
        {<br />
            SimpleServer simpleServer = new SimpleServer(65535, null);<br />
            simpleServer.Start();<br />
           <br />
            System.Net.Mail.MailMessage message = new System.Net.Mail.MailMessage();<br />
            message.To.Add("zxc@abc.com");<br />
            message.From = new MailAddress(this.Text.ToString() + "@youmachine.com", this.Text.ToString());<br />
            message.Subject = "TEST MAIL from " + this.Text.ToString();<br />
            message.Body = "TEST MAIL FROM " + this.Text.ToString();<br />
            SmtpClient smtpClient = new SmtpClient("localhost", 65535);<br />
            smtpClient.Send(message);<br />
           <br />
            simpleServer.Stop();<br />
        }<br />

:? but my application hang at line

<br />
simpleServer.Start();<br />

anybody knows how to use that; actually I am new to C# have worked only on Sun Java

Not Active17-May-10 3:43

Not Active

17-May-10 3:43

Start debugging through the service or contact the author

I know the language. I've read a book. - _Madmatt

msj4u17-May-10 19:18

msj4u

17-May-10 19:18

yeah

already tried that; actually it stuck in the while(true) loop in the Start method.

i think i have to background this (start it as a thread) and move to the next line for connecting to it

any hint or suggestion from where i can get help regarding threads to solve problem like this

Dave Kreskowiak17-May-10 6:05

Dave Kreskowiak

17-May-10 6:05

You'll have to contact the author of SimpleServer to get that solved. I've never heard of it, nor used it.

Your other problem is that most SMTP servers will not relay or receive mail from untrusted sources. So, depending on your mail servers config and the ones you're sending mail to, those servers may just reject your mail and there's nothing you can do about it.

A guide to posting questions on CodeProject[^]

Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009...