|
That depends on your configuration -- usually a release build will use optimizations and the debug doesn't,
and the debug build will include debug symbols and the release doesn't,
so the release version may be quicker and/or more efficient than the debug version.
But you can configure things in other ways if you want.
I have no idea what PDB files do, I wish the compiler wouldn't create them at all, I just delete them and I have no trouble.
|
|
|
|
|
PIEBALDconsult wrote: I have no idea what PDB files do
Its the debugging symbols, its what allows you to break into the code and step through it.
Smart development teams stash away the pdb's from a production release to enable them to debug problems with a specific build of the code at a future date.
|
|
|
|
|
I'm not convinced; I can debug without a PDB file. I believe the debug symbols get built into the EXE.
|
|
|
|
|
You may be able to debug, but you won't get any line numbers without the PDB.
|
|
|
|
|
Then how does the debugger highlight the appropriate line?
|
|
|
|
|
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.)
|
|
|
|
|
No, they don't. More likely VS is being smart enough to locate them under the hood.
More info here[^]
|
|
|
|
|
That doesn't say much; certainly nothing I didn't already know.
|
|
|
|
|
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 
|
|
|
|
|
Eddy Vluggen wrote: A better strategy would be to store everything in SourceSafe
...you mean TFS, right? 
"I need build Skynet. Plz send code"
|
|
|
|
|
Alaric_ wrote: ...you mean TFS, right?
Floppy disk, and store it under a mattress 
I are Troll
|
|
|
|
|
Eddy Vluggen wrote: store it under a mattress
Nah, the princess I'm married to would complain about the lump. 
|
|
|
|
|
|
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).
|
|
|
|
|
You are welcome 
|
|
|
|
|
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.
|
|
|
|
|
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"
|
|
|
|
|
...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"
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
Start debugging through the service or contact the author
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
well if i am able to send the mails; i'll just attach the domain keys not to be marked as spam by the receiving server.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
