Visual Studio doesn't discover my unit tests!

I added a unit test class to a project today, and Visual Studio couldn't find my new unit tests. Quick hack: modify your output window to "Show output from:" "Tests." This may help you find the reason why. In my case, it told me pretty directly what the issue was:

UTA001: TestClass attribute defined on non-public class MyTests

My test class wasn't public, which it appears is a requirement for discovery.

Updating include directories after updating Vivado

So, after updating Vivado, I ended up with a number of warnings during compile in the SDK IDE, referring to an old, now missing path. As the paths didn't appear to be modifiable within the project settings, I searched for a way to update them.

That brought me to this post, which has approximately the right stuff:

1. Close the SDK.
2. Delete the .metadata folder in your xyz.sdk folder.
3. Restart the SDK.
4. Import the existing projects. You'll see that only the design folder was automatically imported.

No matching key exchange method found

Ran into this again while trying to ssh into the old battleship:

no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

A solution is to specify the key exchange algorithm on the command line:

ssh -o KexAlgorithms=+diffie-hellman-group1-sha1 root@169.254.8.70

More information can be found on OpenSSH's Legacy Options page.

Vivado does not launch with Windows 10 Fall Creators Update

There's a work-around available from Xilinx AR 69908. Windows 10 Fall Creators Update is not officially supported for Vivado 17.3 or 17.3.1.

Downloading an ISO for Visual Studio 2017

Note to Self

There isn't an ISO image download for VS 2017, you download the web installer, then pass it the commands to construct a disk layout for you. Here's the location of instructions to do so:

    Create an offline installer for Visual Studio 2017

That page includes instructions for:

• Creating an offline installation layout.
• Installing from an offline installation layout (may not be necessary, see the comments on this instruction).
• Customizing the offline installer.
• Updating the offline installer.
• Troubleshooting.

And here's the command line I use:

    vs_Community.exe --layout c:\vs2017-community-en-US-offline --lang en-US

MMU section translation fault

While working on a ZedBoard (perhaps also MicroZed and others) you may find yourself facing a message referring to MMU section translation fault. This has happened to me a couple times. In my experience it's because I'm attempting to launch a bare metal application to the PS while the board has already booted to Linux--so the MMU is likely already in use. My solution:

• Remove the Linux SD card (from which the board is booting) from the slot and reset the board
• Program the PL (FPGA) again
• Launch your bare metal application again.

Atmel Studio 7 incompatibility with Visual Studio 2015 Update 1

I spent a bit of time baffled after installing Atmel Studio 7.0.634 as I couldn't even create a new project successfully. This appears to be an incompatibility with Visual Studio 2015 Update 1. I found an apparent solution to the issue here, which manages to get me past my issues with creating a project. I'm not exactly sure why Atmel Studio has so many binding redirects, but there it is.

Sample error message: The 'ErrorListPackage' package did not load correctly.

ZedBoard button bit assignments

Future self,

Here are the bit assignments for the five momentary switches on the ZedBoard, as found by experimentation, for your future reference should you ever wish to use them w/GPIO again:

#define BUTTON_CENTER 0x01
#define BUTTON_DOWN   0x02
#define BUTTON_LEFT   0x04
#define BUTTON_RIGHT  0x08
#define BUTTON_UP     0x10

How to undo (almost) anything with Git

via GitHub.com:

https://github.com/blog/2019-how-to-undo-almost-anything-with-git

Detours

This evening I put together an app using an Adafruit PIR (motion) sensor on Win10 for IoT on Raspberry Pi 2. It almost worked the first time, but edge detection in the ValueChanged event on GpioPin gets its value inverted at times. Turns out it's a known issue. My workaround: in the event handler use sender.Read() to get the pin value.

I'll be glad to see this fixed.

Oh, also--the motion sensor prefers 5V over 3.3V. Just sayin'.

Enable "Developer Mode" on Windows 10 build 10074

Here's the trick as currently documented here, as the method to do so through the settings window do not work (for me, Settings, For Developers crashes the settings application):

For Windows 10 desktop
Use gpedit.msc to set the group policies to enable your device, unless you have Windows 10 Insider Preview Home Edition. If you do have Home Edition, you need to use regedit or PowerShell commands to set the registry keys directly to enable your device.

Use gpedit to enable your device

1. Open a cmd prompt with administrator privileges.
2. Run Gpedit.msc.
3. Go to Local Computer Policy > Computer Configuration > Administrative Templates > Windows Components > App Package Deployment
4. Edit the policies to enable the following:
   • Allow all trusted apps to install (Enables your device for sideloading apps)
   • Allows development of Windows Store apps and installing them from an integrated development environment (IDE) (Enables your device for development from Visual Studio)
5. Reboot your machine.

Other methods to do so using regedit and PowerShell are found at the same link.

Upping Raspberry Pi 2's power to the USB ports

Interesting post on upping the Raspberry Pi 2's power to the USB ports. Out of the box the USB peripherals are limited to 600mA.

http://hackaday.com/2015/04/06/more-power-for-raspberry-pi-usb-ports/

Raspberry Pi, Quite Exciting

As I write this i am installing an operating system image on the microSD card of a Raspberry Pi that just arrived. I'm rather surprised at the level of excitement that I feel waiting for it to complete.

Unpacking the Pi reminds me of days long ago when our Atari 800 arrived and shortly thereafter came BASIC, PEEK, POKE, and some 6502 assembler. Yes, 8 KB of RAM, that was living high on the hog. I later parlayed my meager 6502 experience into building a graphical supply-side economics demonstration on the Apple II in high school. Those were the days. (Today, my work machine has 16 GB of RAM--2 million times as much--mostly taken up by web browser programs....)

I expect in coming weeks, as I find time, I'll perform amazing feats such as making an LED light up (no code!) and making an LED flash (a little Python code!) and then doing the same in C++ (okay, where is the right header file?!).

How far will this go? Multiple LEDs of different colors? Multiple concurrent LEDs flash patterns? Wait, can I use the Boost libraries? I bet I can. :) Only time will tell.

WPF Binding Diagnostics

Note to self: when trying to diagnose WPF binding issues, and you want more debug spew, here's that attached property you can't remember:

PresentationTraceSources.TraceLevel

Good luck!

Check yourself

I am humored occasionally at (what I assume is) the rush to get things deployed and the bugs that inevitably appear. Here's a portion of Garmin's "modern" interface for http://connect.garmin.com/ :

"Null" indeed. I suppose I can't complain too much, as I can't really tell what "items" are supposed to appear in this pane. Plenty of options in the contextual menu, but no obvious guidance as to putting things there. :)

Where does legacy code come from?

Q: Where does legacy code come from, anyway?

A: Oh, boy.... Well, you know that code you so lovingly crafted today? That's tomorrow's legacy code.

Portable Class Libraries in F#

Just ran across Using Visual Studio to Write F# Programs, specifically the section "Portable Libraries in F#," which answers a question I had the other day:

Which version of FSharp.Core.dll should I reference in projects that reference my F# PCL assembly?

The link above answers that.

Where Did My Object Go? Part 2

In Part 1 of this article I discussed the possibility of an object instance being collected before a method returns in this scenario:

    new MyObject().LongRunningMethod();

as well as this scenario:

    MyObject o = new MyObject();
    o.LongRunningMethod();

Here we'll discuss how this could become a problem. Frankly, it's pretty easy to cause the problem, but I think it generally involves some ugliness on the part of software design or implementation, largely involving clean-up of fields when the instance is finalized.

Don't Try This at Home

I don't think it's likely you'll see a lot of code that does this, but here's one way to run afoul of your object going way: export a reference to a field that the object cleans up when it's finalized. You can export the reference, say, by making that field visible through a property. Exposing a field that you're going to clean up in the finalizer would be an easy way to create a coupling between your object and other (arbitrary) client code that has no knowledge of your object's life span.

Call Stack Antics

Another way to invoke the potential problem is to lose your "this" reference on the call stack. The code below manages to lose the "this" reference by passing a field to the helper method rather than allowing the helper to access the field directly via its own "this" reference. When the helper tries to access fs.Length an ObjectDisposedException is thrown.

Why does this throw? Well, the last live reference to the instance was lost when LongRunningMethod passed _input to Helper. Essentially we've again exported the field value from the instance and no longer hold a reference to the instance, allowing the GC to finalize it. Helper is left holding a reference to an object that has been finalized.

Note: Again, you will not see this behavior in a debug build. When running code marked as "debug" the JITter extends the lifetime of the local object to the end of the method. So you will not see this effect if you've compiled with the /debug flag.

    using System;
    using System.IO;

    // Ugliness ensues.
    sealed class MyUglyObject
    {
        public MyUglyObject(string inputPath)
        {
            // Real production code would likely not delete the file when done...
            // ...but this is a sample app.
            _input = new FileStream(Path.GetTempFileName(), FileMode.Open, FileAccess.Read, FileShare.Read);
        }

        ~MyUglyObject()
        {
            if (_input != null)
            {
                _input.Close();
                _input = null;
            }
        }

        public void LongRunningMethod()
        {
            Helper(_input); // Our last reference to 'this' (implicit).
        }

        private void Helper(FileStream fs)
        {
            // A long-running method can easily experience a garbage collection 
            // before returning. This one happens for force it to occur.
            GC.Collect();
            GC.WaitForPendingFinalizers();

            // Ka-boom!
            long inputSize = fs.Length;
            // ...
        }

        private FileStream _input;
    }

    class Program
    {
        static void Main(string[] args)
        {
            new MyUglyObject(@"..\..\readme.txt").LongRunningMethod();
        }
    }

Can You See It?

As you can see above it takes a bit of effort to cause the code to blow up. If Helper had used _input.Length instead of taking a parameter the problem would not exist.

But, what I find a bit creepy about the above code is that if Helper were a static method it would seem respectable:

    private static void Helper(FileStream fs)
    {
        // A long-running method can easily experience a garbage collection 
        // before returning. This one happens for force it to occur.
        GC.Collect();
        GC.WaitForPendingFinalizers();

        // Ka-boom!
        long inputSize = fs.Length;
        // ...
    }

At first glance it now looks like helper is a normal static helper function, as is likely seen in code bases across the world. It doesn't need a "this" reference, it takes a reference to the object it uses, everything appears fine on the surface. Would you see the "this" reference being lost by the code calling Helper in a code review? I'm not so sure I would have until recently.

 

 

Technorati tags: Coding, Software Design, CLR, C#, Code Review

Where Did My Object Go? Part 1

I ran across this scenario a few months ago and was just reminded of it. It takes a bit of an edge case to make it a problem, but it's interesting all the same.

There's a regular idiom in C# in which we call a method on an object instance that we've created inline:

    new MyObject().LongRunningMethod();

There assumption may be an assumption that the lifetime of this instance of MyObject extends at least until LongRunningMethod returns, but this isn't necessarily true. This same assumption is often made about local references to objects:

    MyObject o = new MyObject();
    o.LongRunningMethod();

However, in both these cases the object instance may be collected before LongRunningMethod returns.

Does this really happen?

Yes, it can and does. The code below exercises this behavior. When you run it you will see the following output, indicating that the object was collected and finalized before LongRunningMethod returns:

    Using release build
    Inline
    Entering MyObject1.LongRunningMethod().
    Finalizing in ~MyObject1().
    Returning from MyObject1.LongRunningMethod().

    Local reference
    Entering MyObject1.LongRunningMethod().
    Finalizing in ~MyObject1().
    Returning from MyObject1.LongRunningMethod().

Note: You will not see this behavior in a debug build. When running code marked as "debug" the JITter extends the lifetime of the local object to the end of the method. So you will not see this effect if you've compiled with the /debug flag.

Note also that this article also assumes we're using CLR 2.0. Future versions could obviously behavior differently.

Here's the code. Just drop it into test.cs, run csc test.cs, and execute test.exe.

    using System;

    sealed class MyObject
    {
        ~MyObject()
        {
            Console.WriteLine("Finalizing in ~MyObject1().");
        }

        public void LongRunningMethod()
        {
            Console.WriteLine("Entering MyObject1.LongRunningMethod().");

            // A long-running method can easily experience a garbage collection 
            // before returning. This one happens for force it to occur.
            GC.Collect();
            GC.WaitForPendingFinalizers();

            Console.WriteLine("Returning from MyObject1.LongRunningMethod().");
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
    #if DEBUG
            string build = "debug";
    #else
            string build = "release";
    #endif
            Console.WriteLine("Using {0} build", build);

            // Try it both ways.

            Console.WriteLine("Inline");
            new MyObject().LongRunningMethod();

            Console.WriteLine();
            Console.WriteLine("Local reference");
            MyObject o = new MyObject();
            o.LongRunningMethod();
        }
    }

Is this a problem?

Generally, I'd say it's not a problem. Once it has begun execution, LongRunningMethod doesn't need the original object reference unless it's making reference to that instance. In that case the GC won't be able to collect the object.

I'll discuss how to make it a problem in Part 2 of this article.

 

Technorati tags: Coding, Software Design, CLR, C#

File. Close. No!

I enjoyed listening to Scott Hanselman's podcast interview of Larry Osterman today. Larry has been working at Microsoft for more than 23 years now and usually has words of interest to software developers on his blog.

As the discussion turned to security issues I was reminded of a security issue I pointed out to a colleague back in, well, I believe it was the first half of the 90's. The issue: the attack vector brought about by speaker-independent voice recognition. The scenario: the disgruntled office worker running through the cubicle farm, shouting "File. Close. No! File. Close. No!"

It amuses me to think that perhaps the new ribbon-and-pearl command structure of Office 2007 apps has gone a long way in negating that issue. :)

 

Technorati tags: Security