fbpx

Made in USA: Enterprise Application Services

Ringing PhoneCall Today!817-210-4042

c# Archives - Ayoka - Made in USA Enterprise Application Services

C# Development Company News: Version Seven Is Underway

October 15, 2015
|
0 Comments
|
c sharp development companyOur custom software and C# development company takes a peek at what’s on the table for Version 7.

As a US-based C# development company, we like to keep up with everything that’s going on with Microsoft programming languages. In Version 6.0 of C# that shipped with VisualBasic this year, developers got access to some cool features like exception filters and the “using” statement to support writing code that’s less cluttered and redundant. There’s also the Roslyn compiler which is open source and available “as a service” with a rich set of API libraries. But even more good stuff is in the works for the next version.

Data Management Leads the Wish List for Version 7

There’s still a lot of speculation about which new features will end up in C# 7. Paul Krill at InfoWorld gives a solid rundown of what’s on the “Strong Interest” list all the way down to the “Don’t Hold Your Breath” section. He mentions the strong focus on data performance and reliability with significant interest in tuples for temporarily grouping a set of values.

Mads Torgersen, Program Manager for the C# Language, says the team is looking to functional languages like F#, Scala, and Swift for inspiration on how to better manage data: “Functional programming languages are often better set up for this: data is immutable (representing information, not state), and is manipulated from the outside, using a freely growable and context-dependent set of functions, rather than a fixed set of built-in virtual methods.”

At Ayoka, we have a strong background in database development and optimization, so we’re looking forward to using these new tools for our clients! If your company uses MS software and needs custom options, give us a call at 817-210-4042 for a consultation.

Debug and Trace in C#

August 4, 2009
|
0 Comments
|

.NET offers some very useful classes that allow you to monitor the workings of your program without having to constantly pop up message boxes or handle file output yourself.  Both of these classes have listener objects (the list is shared; adding a listener to Trace also adds it to Debug) which can be text files or streams you assign.

By default, the Debug class is not compiled in release mode, while the Trace class is functional in both modes.

Some of the more useful functions and properties in these classes are described below.  These are rough descriptions and more details are available on the MSDN (links are provided).

FunctionDescription
AssertChecks for a condition. If the condition fails, it presents a message box.
FlushFlushes the output buffer for the class and for all listeners.
IndentIndents the output by one unit. Affects all following messages.
UnindentRemoves one unit from the output. Affects all following messages.
Write
WriteLine
Writes to the output panel in Visual Studio and to the trace listener objects.
WriteIf
WriteLineIf
Writes only if the condition is met.

 

PropertyDescription
AutoFlushWhether Flush() should be called on the listeners after every write.
IndentLevelThe number of indent units currently in place.
IndentSizeThe number of spaces used per indent unit.
ListenersThe list of TraceListener assigned to Debug and Trace.

 

Trace and Debug can be very powerful development tools that can help kill hard to find bugs by making them glaringly obvious. The Write and Assert functions can provide great detail as to what is happening inside your program. Your client is not running a debugger for you, but it’s easy for them to email you the error.txt file that is in thier program directory.

Write and the conditional Write function can be very useful for outputting exceptions, even the ones you are able to recover from.  It helps to find bugs that may not show up right away. Doing little things like making sure nothing added to a list is null can go a long way towards tracking down hard to find errors.

The Assert function is more useful during development than during release. Using Debug.Assert() instead of Trace.Assert() makes it easy to leave your assertions in during development, but make sure the users never have trouble with them. When something should never happen, toss an assert there to make sure. It’s amazing how often your software will try to divide by zero or convert null to a string.