|
in .NET an ASCII character is just a character, the first 128 Unicode characters ARE the ASCII characters.
So
'a'
"a"[0]
(char)97
are all the same lower-case a, as they are
a character literal
the way to get the first character of a string
a number cast to a character
If you don't understand the fundamentals, go buy a book and study it. If you have an overall problem, tell us about the problem rather than asking a detail question on what probably isn't even the right detail.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
There is no equivalent; C# developers are smart enought not to write anything as silly as that. 
|
|
|
|
|
thank you it's like that when sharing information has a beginning researcher in c #
thank you very much
|
|
|
|
|
Sure, however you should allow some slack for VB coders trying to spit out some C#.
How about
char ascee='0';
char uniquode=Encoding.UTF8.GetChars(Encoding.ASCII.GetBytes(new char[]{ascee}))[0];
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
the out result is the same of first value of ascee no chage ???
|
|
|
|
|
Luc Pattyn wrote: allow some slack for VB coders
They made their sty they can wallow in it.
|
|
|
|
|
sig material it is.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
Hi everybody. ...It's been way too long since I've had to issue a production release, but guess what I get to do this week lol
..at any rate, I'm writing up the installme.doc checklist for Production Management to be able to roll our code out to production, and I ran into something that I'm curious to know everyone's thoughts on:
1)Are there any tangible benefits to issuing a true "Release" build to production?
2)Or does it suffice to merely build in "Debug" and not copy over the pdb file that is generated with it?
3)Are they equivalent processes and issuing a "Release" build is merely more explicit in stating "This is built for a production release?"
(Our current SOP is #2)
Thoughts, opinions (other than a mere msdn reference...I'm requesting information from real world experience with the two methods)
"I need build Skynet. Plz send code"
|
|
|
|
|
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"
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
