C# 10.0 All-in-One for Dummies – John's Random Thoughts and Discussions

IDE Screenshot Usage in Books

There are cases where it’s very tough to figure out the correct presentation of material in a book, which is made more difficult by some readers preferring one presentation and other readers another. It comes down to how people learn in many cases. Visual learners prefer screenshots, abstract learners prefer text. Of course, there are all sorts of learners between these two extremes. So, what seems like a simple question can become quite complex.

The question at hand is whether to present screenshots of an IDE in a book with the associated example code and its output. The problem is that vendors now assume that developers have very large displays and so have made use of all of that extra screen real estate. In addition, book publishers don’t want books where a single image consumes an entire page. The result is that it’s very hard to get a screenshot where the text is completely readable. It can be done, but the text will generally still be smaller than the print in the book. Older readers complain that they need a magnifying glass to see the text at all.

However, there are benefits to using screenshots. The most important benefit is that, even if the text isn’t completely readable, visual learners can see what their IDE should look like as they follow the progress of procedures in the book. This feedback lets the visual learner know that they are doing things correctly and are getting the correct result. Another benefit is that an example tends to stay in one piece. The graphical output of an example doesn’t end up several pages away from the source code that produces it. Sometimes, textual output is wider than the page will allow using the normal font size. So, the options are to print the output in the book at the normal font size, but in a truncated form, which means that it’s no longer complete. A screenshot can show the complete textual output, but at a smaller font. For beginner readers, the second form, while not optimal, is preferred because truncating the output produces questions in the reader’s mind.

So, how do you feel about IDE screenshots in books? Are they more helpful or more confusing? Part of the reason for posts like this is to get your opinion and discover more about you as a reader. Obviously, a book author wants to use the communication techniques that work best overall for everyone, book space often not allowing for the investigation of every presentation alternative. Let me know your thoughts at [email protected].

Giving Hackers an Exciting Target

Hackers will attack anyone, any organization, or anything that seems to offer the promise of something in exchange for the time spent: money, resources, revenge…the list goes on. However, for many hackers the kicker for choosing somewhere to hit is some level of challenge, some sort of excitement. After all, why attack a boring site when there is one out there literally begging you to attack it? Such is the case with GrapheneOS, which bills itself as:

The private and secure mobile operating system with Android app compatibility.
GrapheneOS Website

According to Multiple DDoS Attacks at GrapheneOS — What’s Going On Behind the Scenes?, GrapheneOS has recently endured multiple attacks. I verified the story on Twitter from a post by GrapheneOS. Such an attack can happen to anyone at any time. Keeping a low profile seems prudent, but not always possible (as is the case here). One of the things I stressed when writing Machine Learning Security Principles is that anything an organization can do to make attacks harder and less attractive will only reduce the security burden of the organization in the long run. Keeping a low profile tends to make an attack less attractive.

The reason that I was attracted to this particular DDoS attack is that GrapheneOS is using Synapse, an AI-based product. The article, Synapse Technology Corporation: Using AI to Take a Good Look at Airport Security, tells you a bit more about the history of this product. In looking at the Synapse website, you can see that they have some interesting customers, including the military and government. Oddly enough, I’m not seeing any other reports of major problems with Synapse. The problem must be with the GrapheneOS security setup.

The bottom line is that if a hacker decides to break into your organization, it’ll happen at some point no matter how good your security systems are, which means that it’s essential to combine security with monitoring and analysis of attack vectors. Keeping a low profile is essential too because hackers, like the most of the rest of us, love a good challenge. Reviewing attacks like the ones targeted at GrapheneOS can help you improve your own security setup. Let me know your thoughts on AI-based security at [email protected].

Comment and Document Updates for CI/CD

In reading about Continuous Integration/Continuous Deployment (CI/CD) I often find ways to manage the code, to get people around the code, to keep errors out of the code, and so on. It’s all about the code. Developers have, in fact, developed myriad ways to keep code size small, updated, deployed, tested, and so on to ensure that users have what they want, when the they want it (if not before). Sometimes my head spins on its axis after reading such documents because it becomes a high speed dizzying affair. It’s somehow assumed that everyone can just keep up. Except, there are new people and older people and people with lesser attention spans who can’t keep up, which is why comments and documentation are so important.

As part of the coding process, developers also need to update both comments and documentation or someone will come along and make modifications based on outdated information. Even though making such updates seems like a waste of time since everyone should be able to keep up, the truth is that these updates ultimately save time. However, the updates, when they occur (which apparently isn’t often) are often made in a haphazard manner reminiscent of an old Keystone Cops movie.

Adding a process, a workflow, to the CI/CD mill is important to ensure that everything remains in sync: code, comments, and documentation. A best practice way to accomplish this task is to add steps to every update process so that nothing is left behind. Here’s how you could approach the problem:

Perform the required code updates.
During testing, ensure that the comments within the code actually match what the code is doing. Testing and other review processes should not only look at the code, but the comments too.
Update the documentation as final testing occurs. Make sure to include these elements:
- Text
- Drawings
- Mockups
- Visual Aids
- Videos
- Any other documentation elements
Specify that any old comments/documentation are outdated using one of these approaches:
- Mark it as deprecated
- Remove it from the work area and put it in an archive
- Delete it completely
Deploy the application update. If you don’t deploy the update after these steps are done, they won’t get done. Everyone will wander off somewhere and forget all about any sort of comment or documentation update.

Obviously, the approach you end up using has to meet the requirements of your organization. It also has to be simple enough that people will actually, albeit begrudgingly, perform the work. What methods do you use to keep everything in sync at your organization? Let me know at [email protected].

Antivirus and Application Compilation

This is an update of a post that originally appeared on April 2, 2014.

Sometimes applications don’t get along, especially when one application is designed to create new content at a low level and the other is designed to prevent low level access to a system. Such is the case with compilers and antivirus applications in some cases. I haven’t been able to reproduce this behavior myself, but enough readers have told me about it that I feel I really do need to address it in a post. There are situations where you’re working with source code from one of my books, compile it, and then have your antivirus application complain that the code is infected with something (even though you know it isn’t). Sometimes the antivirus program will go so far as to simply delete the application you just compiled (or place it in a virus vault).

The solution to the problem can take a number of forms. If your antivirus application provides some means of creating exceptions for specific applications, the easiest way to overcome the problem is to create such an exception. You’ll need to read the documentation for your antivirus application to determine whether such a feature exists. In most cases today, antivirus applications also provide settings that accommodate specific applications and you’ll want to check with the antivirus vendor and/or community support to see if this need has been met.

In some cases, the compiler or its associated Integrated Development Environment (IDE) simply don’t follow all the rules required to work safely in protected directories, such as the C:\Program Files directory on a Windows system. As far as I know, all of the development environments currently used in my books do follow the rules, so you shouldn’t have a problem in this area, but please let me know if you do. Often, the workaround for this problem is to install the application in a directory that the user owns and just avoid the security issue.

Not including the application in the Windows path can cause problems and I cover this issue in the Adding a Location to the Windows Path post. In addition, there are problems with installing the source code in a path containing spaces or lacks proper access. I discuss these issues in the Source Code Placement post.

Unfortunately, creating exceptions and installing the application in a friendly directory only go so far in fixing the problem. A few antivirus applications are so intent on protecting you from yourself that nothing you do will prevent the behavior. When this happens, you still have a few options. The easiest solution is to turn the antivirus program off just long enough to compile and test the application. Of course, this is also the most dangerous solution because it could leave your system open to attack.

A safer, albeit less palatable solution, is to try a different IDE and compiler. Antivirus programs seem a little picky about which applications they view as a threat. Code::Blocks may cause the antivirus program to react, but Eclipse or Visual Studio might not. Unfortunately, using this solution means that steps in the book may not work precisely as written. In addition, unless the compilers are compatible, the book’s source code may not compile at all without changes. Because I can’t cover every contingency, I also can’t support using a compiler other than the one specifically called out in a book.

Getting a different antivirus application is also a good idea. Antivirus applications and IDEs have come a long way since I originally created this post, but some antivirus applications really don’t work well and create more headaches than they’re worth. The choice is up to you, of course, but with the wealth of antivirus programs available on the market today, there isn’t a good reason to avoid getting something new when the situation warrants.

My goal is to ensure you can use the examples in my books without jumping through a lot of hoops. When you encounter problems that are beyond my control, such as an ornery antivirus application, I’ll still try to offer some suggestions, but I can’t take time to fix your system. In this case, the solution truly is out of my control but you can try the techniques offered in this post. Let me know if you find other solutions to the problem at [email protected].

Creating Sensible Error Trapping

This is an update of a post that originally appeared on May 23, 2011.

Errors in software happen. A file is missing on the hard drive or the user presses an unexpected key combination. There are errors of all shapes and sizes; expected and unexpected. The sources of errors are almost limitless. Some developers look at this vastness, become overwhelmed, and handle all errors the same way—by generating an ambiguous exception for absolutely every error that doesn’t help anyone solve anything. This is the worst case scenario that’s all too common in software today. I’ve talked with any number of people who have had to employ extreme effort just to figure the source of the exception out; many people simply give up and hope that someone has already discovered the source of the error.

At one time, error handling functionality in application development languages was so poor that it was possible to give the developer the benefit of a doubt. However, with the development tools that developers have at their disposal today, there is never a reason to provide an ambiguous “one size fits all” exception. For one thing, developers should make a distinction between the expected and the unexpected. Any expected error—a missing file for example—should be handled directly and specifically. If the application absolutely must have the file and can’t recreate it, then it should display a message saying which file is missing, where it is missing from, and possibly how to obtain another copy.

Even more than simply shoving the burden onto the user, however, modern applications have significantly more resources available for handling the error automatically. For example, it’s quite possible to use an Internet connection to access the vendor’s Web site and automatically download a missing application file. Except to tell the user what’s happening when the repair will take a few minutes, the application shouldn’t even bother the user with this particular kind of error—the repair should be automatic.

All of my essential programming books include at least mentions of error handling, debugging, exceptions, and other tasks associated with running code efficiently and smoothly. For example, Part IV of C++ All-In-One for Dummies, 4th Edition is devoted to the topic of debugging. Part V Chapter 3 of this same book talks about exceptions. If you’re a C# developer, C# 10.0 All-in-One for Dummies discusses exception handling in Book I Chapter 9. Book IV Chapter 2 discusses how to use the debugger to find errors. The point is that it’s essential to handle errors in your applications in a manner that makes sense to the users who rely on the application daily and the developers who maintain it.

Note that many of my newer books provide instructions for working with online IDEs, most especially Google Colab. These online IDEs rarely provide built-in debugging functionality, so then you need to resort to other means, such as those expressed in Debugging in Google Colab notebook.

Exceptional conditions do occur. However, even in these situations the developer must avoid the generic exception at all costs. If an application experiences an unexpected error and there isn’t any way to recover from it automatically, the user requires as much information as possible about the error in order to fix it. This means that the application should diagnose the problem as much as possible. Don’t tell the user that the application simply has to end—there is never a good reason to include this sort of message. Instead, tell the user that the application can’t locate a required resource and specify the resource in as much detail as possible. If possible, let the user fix the resource access problem and then retry access before you simply let the application die an ignoble death. Remember this! Any exception that your application displays means that you’ve failed as a developer to locate and repair the errors, so exceptions should be reserved for truly exceptional conditions.

Not everyone agrees with my approach to error trapping, but I have yet to hear a convincing argument to provide unreliable, non-specific error trapping in an application. Poor error trapping always translates into increased user dissatisfaction, increased support costs, and a reduction in profitability. Let me know your thoughts on the issue of creating a sensible error trapping strategy at [email protected].

An Update on the RunAs Command

This is an update of a post that originally appeared on May 14, 2014.

Recently I wrote the Simulating Users with the RunAs Command post that describes how to use the RunAs command to perform tasks that the user’s account can’t normally perform. (The basics of using the RunAs command appear in Windows Command-Line Administration Instant Reference.) A number of you have written to tell me that there is a problem with using the RunAs command with built-in commands—those that appear as part of CMD.EXE. For example, when you try the following command:

RunAs /User:Administrator "md \Temp"

you are asked for the Administrator password as normal. After you supply the password, you get two error messages:

RUNAS ERROR: Unable to run - md \Temp
2: The system cannot find the file specified.

In fact, you find that built-in commands as a whole won’t work as anticipated. One way to overcome this problem is to place the commands in a batch file and then run the batch file as an administrator. This solution works fine when you plan to execute the command regularly. However, it’s not optimal when you plan to execute the command just once or twice. In this case, you must execute a copy of the command processor and use it to execute the command as shown here:

RunAs /User:Administrator "cmd /c \"md \Temp""

This command looks pretty convoluted, but it’s straightforward if you take it apart a little at a time. At the heart of everything is the md \Temp part of the command. In order to make this a separate command, you must enclose it in double quotes. Remember to escape the double quote that appears within the command string by using a backslash (as in \").

To execute the command processor, you simply type cmd. However, you want the command processor to start, execute the command, and then terminate, so you also add the /c command line switch. The command processor string is also enclosed within double quotes to make it appear as a single command to RunAs.

Make sure you use forward slashes and backslashes as needed. Using the wrong slash will make the command fail.

The RunAs command can now proceed as you normally use it. In this case, the command only includes the username. You can also include the password, when necessary. Let me know if you find this workaround helpful at [email protected].

Creating Useful Comments

This is an update of a post that originally appeared on November 21, 2011.

A major problem with most applications today is that they lack useful comments. It’s impossible for anyone to truly understand how an application works unless the developer provides comments at the time the code is written. In fact, this issue extends to the developer. A month after someone writes an application, it’s possible to forget the important details about it. In fact, for some of us, the interval between writing and forgetting is even shorter. Despite my best efforts and those of many other authors, many online examples lack any comments whatsoever, making them nearly useless to anyone who lacks time to run the application through a debugger to discover how it works.

Good application code comments help developers of all stripes in a number of ways. As a minimum, the comments you provide as part of your application code provides these benefits.

Debugging: It’s easier to debug an application that has good comments because the comments help the person performing the debugging understand how the developer envisioned the application working.
Updating: Anyone who has tried to update an application that lacks comments knows the pain of trying to figure out the best way to do it. Often, an update introduces new bugs because the person performing the update doesn’t understand how to interact with the original code.
Documentation: Modern IDEs often provide a means of automatically generating application documentation based on the developer comments. Good comments significantly reduce the work required to create documentation and sometimes eliminate it altogether.
Technique Description: You get a brainstorm in the middle of the night and try it in your code the next day. It works! Comments help you preserve the brainstorm that you won’t get back later no matter how hard you try. The technique you use today could also solve problems in future applications, but the technique may become unavailable unless you document it.
Problem Resolution: Code often takes a circuitous route to accomplish a task because the direct path will result in failure. Unless you document your reasons for using a less direct route, an update could cause problems by removing the safeguards you’ve provided.
Performance Tuning: Good comments help anyone tuning the application understand where performance changes could end up causing the application to run more slowly or not at all. A lot of performance improvements end up hurting the user, the data, or the application because the person tuning the application didn’t have proper comments for making the adjustments.

The need for good comments means creating a comment that has the substance required for someone to understand and use it. Unfortunately, it’s sometimes hard to determine what a good comment contains in the moment because you already know what the code does and how it does it. Consequently, having a guide as to what to write is helpful. When writing a comment, ask yourself these questions:

Who is affected by the code?
What is the code supposed to do?
When is the code supposed to perform this task?
Where does the code obtain resources needed to perform the task?
Why did the developer use a particular technique to write the code?
How does the code accomplish the task without causing problems with other applications or system resources?

There are many other questions you could ask yourself, but these six questions are a good start. You won’t answer every question for every last piece of code in the application because sometimes a question isn’t pertinent. As you work through your code and gain experience, start writing down questions you find yourself asking. Good answers to aggravating questions produce superior comments. Whenever you pull your hair out trying to figure out someone’s code, especially your own, remember that a comment could have saved you time, frustration, and effort. What is your take on comments? Let me know at [email protected].

JavaScript and Memory Leaks

This is an update of a post that originally appeared on January 25, 2013.

I’ve written any number of books that either include JavaScript development directly or indirectly. For example, when you create a web application in C#, there is some JavaScript involved that might ruin your day unless you have some idea of what that code is doing and how it can go wrong. If you enable JavaScript on your Android phone or tablet, then you can also use JavaScript development techniques in that environment. Because JavaScript provides a well-known and standardized environment, you often find it used in places where you may not think to look, which means taking the time to actually review the code that your IDE generates for web-based applications.

One of my goals in writing a book is to introduce you to techniques that produce useful applications in an incredibly short time without writing bad code. The term bad code covers a lot of ground, but one of the more serious issues is one of memory leaks. Applications that have memory leaks will cause the application and everything else on the system to slow down due to a lack of usable memory. In addition, memory leaks can actually cause the application to crash or the system to freeze when all of the available memory is used up. So, it was with great interest that I read an LogRocket article recently entitled, How to escape from memory leaks in JavaScript. The article contains a lot of useful advice in writing good JavaScript code that won’t cause your users heartache.

One of the most important parts of this article is that it covers memory leaks as a process. There is a list of common memory leak types and how to identify them. It also introduces you to tools and techniques for fixing memory errors using Chrome DevTools.

It’s essential to know that this article doesn’t cover everything. A big one is that the memory leak you’re seeing in your application may not be due to your code—it may be caused by the browser. The potential for browser problems is an important one to keep in mind because these issues affect every application that runs, not just yours. However, when your application performs a lot of work that requires heavy memory use, the user may see your application as the culprit. It pays to track browser issues so that you can support your users properly and recommend browser updates for running your application when appropriate. For that matter, you can simply determine whether the user has one of the poorly designed browsers and tell the user to perform an update instead of running the application.

There are other potential sources of memory leaks. For example, using the wrong third party library could cause considerable woe when it comes to memory usage (amongst other issues). Consequently, you need to research any libraries or templates that you use carefully. The libraries, templates, and other tools discussed in my books are chosen with extreme care to ensure you get the best start possible in creating JavaScript applications.

One of the reasons I find JavaScript so compelling as a language is that it has grown to include enough features to create real applications that run in just about any browser on just about any platform. The ability to run applications anywhere at any time has been a long term goal of computer science and it finally seems to be a reality at a certain level. What are your thoughts on JavaScript? Let me know at [email protected].

Checking SQL Server Status

This is an update of a post that originally appeared on November 14, 2012.

A number of my books rely on database access. Today that database access can take many forms, such as the use of .csv files in my AI, machine learning, and deep learning books. However, this post is specific to those books that use Microsoft’s SQL Server on the local system, which is currently limited to C++ All-In-One for Dummies, 4th Edition (optionally) and C# 10.0 All-in-One for Dummies, but could include other books in the future (or you may simply decide to use Microsoft SQL Server with one of my other books).

In order to access any server, the server must be running. It only makes sense that you can’t access something that isn’t listening. The problem is that SQL Server may not start automatically for a number of reasons on your system and that Visual Studio doesn’t always make it apparent that the server isn’t running. You may get a nebulous message when you try to make a connection that doesn’t tell you anything. (No, SQL Server doesn’t start automatically when you make a request for data.) With this in mind, a post of checking the status of SQL Server is important.

Normally, I would tell you to use the tools that come with SQL Server to check the status of the server. However, some versions of SQL Server Express Edition install without the standard tools now, such as SQL Server Management Studio (SSMS). Without access to these tools, it may seem as if checking the server status is impossible. Fortunately, you have other options.

The best way to check the status of SQL Server on your system is to use the Services console found in the Administrative Tools folder of the Control Panel. The Services console is one of a number of Microsoft Management Console (MMC) snap-ins that Windows installs automatically for you. However, to use this console, you must have administrator rights on the target system. Without these rights, you truly are out of luck in checking the status of your SQL Server setup and will need to get an administrator to help you.

Open the Services console by right clicking Start, choosing Run from the menu, typing services.msc in the Open field, and clicking OK. You find a list of all of the services installed on your system in the resulting Services window. Scroll down the list and you should find one or more SQL Server entries like the ones shown here.

The services window contains a list of Windows services installed on the local machine that their status. — Use the Services console to check the status of services on your system.

In order to work successfully with the examples in my book, you should have SQL Server set to start automatically. In addition, when you check the service, you should see Started in the Status column as shown in the screenshot. If you don’t see Started, then highlight the service as shown and click the Start link you see on the left side (not shown in this case because the service is already started).

To make the examples easier to work with, you should also ensure that the SQL Server Browser service is started. This service makes it possible for Visual Studio to find the SQL Server installation on your system. Without this service, you must correctly type the name of the SQL Server installation you want to use when creating a connection, which is both time consuming and error prone.

If you find that you encounter problems making database examples in my books work, please check the status of SQL Server to ensure the service is actually started. Contact me at [email protected] if you experience any other connectivity problems. I may not be able to fix every problem you encounter, but I often have a good idea of what problems you might be seeing on your system and will do my best to help you.

S	M	T	W	T	F	S
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31

Category: C# 10.0 All-in-One for Dummies