Tagged with C#
[UPDATE] After reviewing some of the code and talking with commenters, I agree that using HostServices for console apps is a bad idea. I've refactored this to use the host but not the HostService. I believe that the entire host is still useful for configuration, logging, and DI. See below for the latest changes:
I was at a customer site last week and a lot of their integration code is a set of console apps that are run on timers to import and export data. This isn't an uncommon use-case.
I've got a couple of these lying around myself. I realized that I didn't know of a good exemplar of doing simple console apps using .NET Core in a way that is closer to ASP.NET Core (e.g. dependency injection, lifetime management, cancellation, etc.). So I decided to re-write an old console app I have.
I'm finally getting around to looking at updating my examples and courses to 3.0. This post is based on .NET Core Preview 8 so this might change in the future.
There are a number of great walkthroughs for moving your ASP.NET Core 2.x projects to 3.0. So I don't want to repeat that. Instead, I want to talk about what's happening, not just a list of things to do.
To discuss these changes, i'll talk about a project I'm current converting (CoreCodeCamp which is the basis for the Atlanta Code Camp), though it's a branch that likely won't be deployed until after the event.
I’ve known Glenn Block for a long time now and I’ve heard about the ScriptCS project he’s worked on for a long time. I’ve never had time to dig in until now.
For the uninitiated, ScriptCS is a scriptable environment that uses .NET and C# for it’s platform. It makes writing simple scripts easier if you know C# already. It has support in several different editors, but I’ll talk about how I used it with Visual Studio Code since that’s my new favorite toy.
Before I can learn something interesting I have to have a job to do. In this case I had a simple problem: I needed to clean up Visual Studio projects. I create a *lot* of projects. Whether they are examples for courses, talks, or for my own investigations, I end up with projects lying around everywhere. Before I could share them, I want to clean them of temporary data (e.g. bin and obj directories, et al). Now that I use GitHub for many of these projects, cleaning isn’t that important but even in that case I still have a lot of disk space devoted to these files, so I still want to clean them up.
I am getting married and that means I get a bunch of development tasks to do for the wedding planning. I guess it’s my own fault, I did propose with an app.
One of the tasks I had to do was create a new page on my wedding site for the day of the wedding to include things like directions and parking. Pretty simple HTML stuff, but one thing I wanted to be sure of was to only show the page on the day of the wedding. This should be easy, but the time zone of the server has kicked my ass before.
The problem is that if I check for the date, the date might get shifted if the time is after midnight where the server is. Luckily the TimeZoneInfo class makes this pretty easy in C#. The trick is to first get the time zone you care about:
As a C# guy I am comfortable with the idea of 'this' in the scope of a class (or 'Me' for your VB'ers). It's a relatively simple idea that allows you to access the instance of the class that you're a part of to call members.
If we have global code (outside objects or functions) and check the 'this' object, it usually returns the "Window" object in the DOM:
When I teach Silverlight, some of the students lament at the requirement to make all network requests in an asynchronous manner. While I explained my opinion on the manner back in March of this year, I didn't get into how to make this easier. Lambdas and closures are the key to simplifying that code in my opinion.
Let's take the example of making a call to a simple web service. I will show you two examples to try and get my idea across. First we have a simple web service that returns a list of Game objects based on a single criterion (the genre). Calling this service is simply a matter creating the client, registering the event handler and calling the asynchronous method:
Interestingly, Microsoft has released a new tool that they've used for years internally to analyze code in their code base. Its been informally called "StyleCop" and differs from FxCop in that it analyzes source code, not compiled binaries.
If you are interested in consistency in your code base, you should take a look!
This weekend I will be at the Atlanta Code Camp this Saturday. I have four talks and they follow the predictable Silverlight and Data topics. Here are the talks:
In addition, we giving away a seat at the upcoming Atlanta stop of the Silverlight Tour (on May 12-14th, 2008). Com early and state late to be there for the drawing. The code camp is giving away a number of prizes, this is just one of them.
I was reading an article about VB9's XML Literal support and why C# decided not to support it. (Note, I agree with C#'s lack of support for it, but that's not what this post is about). Paul Vick said:
While I agree with this notion, this seems to be the exact reason for *not* including LINQ. Why are they willing to tie the language to a brand-new notion of language integration that might not be here in two years, but they saying they don't want to pollute the language with XML becuase they are not sure it will be here soon?
Interesting what can happen when you re-read the specification. I've been taking time in the "library" to read the 2.0 C# Specification. But instead of skiping the old stuff and concentrating on the new language stuff, I am reading the whole thing again. Something interesting I found in the 'switch' statement.
I am an old C++ hack from the COM days so I assumed that I knew how the switch worked:
There is a suggestion up on the LadyBug site to support a Beta 3 of Visual Studio as some developers are worried about the quality of the Beta 2 (and I assume the CTP's as well). If you have an opinion (I have one), please go there and Vote. The sheer size of the votes will help Microsoft determine if it is a fringe group believes there are issues or whether a Beta 3 is really necessary. Please make your opinion known!
I found it very interesting in a little test that the Flags attribute doesn't seem to change the way that the CLR numbers Enumerations. So that this enumeration:
public enum UnFoo
this code ends up not working as i'd expect:
Foo f = Foo.Foo | Foo.Bar | Foo.Quux;
this results in:
I got to play with an Itanium 2 Box at the PDC today. Instead of following their script, I did what I've wanted to do for months...creating a huge DataSet. They had an interesting setup. You used a Pentium 4 box to develop code and then Terminal Service'd into a sixteen-way Itanium 2 machine to run the code. The 64 bit JIT's the IL to 64 bit code from the same assembly that the 32 bit JIT did to create the 32 bit code.
I say some interesting results:
With some encouragement by the Microsoft staff, we tested 4, 8 and 16 gig DataSets. Wahoo..it worked fine. There was a small problem with some internal issues with multiple threads and the DataSet, but that's to be expected. The 64 bit CLR is still pretty early on.
Everytime I add a app.config file to a new C# App, it never does what I want. I want the app.config file to be deployed to the build directory so I can make changes to the app.config file and have it propogated. With the release of VS.NET 2003, us C# developers now have pre and post build steps. So I now have to remember to add the following to the post-build event:
xcopy /s $(ProjectDir)app.config $(TargetPath).config
I know I could write an "Add New Item" to make it happen, but I just haven't had the time. I just wish MS had done it for me.
Chris Sells has alerted me to the fact that if your project has a app.config file, VS.NET 200X will copy it and rename it for you. My bad. I could have sworn that I tried this before and it didn't work : (