Different behavior on different machines
-
I've noticed that sometimes, specific parts of my application will run on my machine differently than the machine that it is actually intended to be run on. For instance, my computer, the one I am using to develop this application, there are MANY instances where the program has run flawlessly. However, when I move the application to the computers where it will be run, some things will either respond differently, or cause a crash. Examples of this include objects being disposed too early on the live-system machines, causing a crash. These same objects are alive and working fine at the same stages on the development machine. Another example is I want to simply position a button inside of a textbox (this is embedded in a datagrid column). Works fine on the development machine, and the button always shows up properly, and in the correct placement. However, on the live-system, the button seems to have a mind of its own, sometimes showing up, sometimes not, and usually always positioned in the wrong place. So what is the deal with this type of behavior? Is this something that programmers will have to constantly deal with if using the .NET environment? The development and live-system computers all are running the same versions of the .NET Framework. I just don't get it. It is difficult to fix a problem when I can't duplicate the cause. Is this an inherent result of C#, or .NET, programs compiling as they are being run? I like the idea that they are actually being optimized for the specific machine they are being run on, but is the optimizer causing my programs to run differently on different machines? If that isn't causing the problem, then what in the world could it possibly be? I'm open to a lot of suggestions here! Thanks, I hope somebody (Heath...hint hint) can help me out here. :-D
-
I've noticed that sometimes, specific parts of my application will run on my machine differently than the machine that it is actually intended to be run on. For instance, my computer, the one I am using to develop this application, there are MANY instances where the program has run flawlessly. However, when I move the application to the computers where it will be run, some things will either respond differently, or cause a crash. Examples of this include objects being disposed too early on the live-system machines, causing a crash. These same objects are alive and working fine at the same stages on the development machine. Another example is I want to simply position a button inside of a textbox (this is embedded in a datagrid column). Works fine on the development machine, and the button always shows up properly, and in the correct placement. However, on the live-system, the button seems to have a mind of its own, sometimes showing up, sometimes not, and usually always positioned in the wrong place. So what is the deal with this type of behavior? Is this something that programmers will have to constantly deal with if using the .NET environment? The development and live-system computers all are running the same versions of the .NET Framework. I just don't get it. It is difficult to fix a problem when I can't duplicate the cause. Is this an inherent result of C#, or .NET, programs compiling as they are being run? I like the idea that they are actually being optimized for the specific machine they are being run on, but is the optimizer causing my programs to run differently on different machines? If that isn't causing the problem, then what in the world could it possibly be? I'm open to a lot of suggestions here! Thanks, I hope somebody (Heath...hint hint) can help me out here. :-D
First off, please don't address me personally. I'm flattered, but it's not very nice to others with good answers like Nick and Dave and others that show up from time to time. Second, keep in mind that the .NET Framework - while the same on all Windows platforms (save the differences between Windows and Windows NT, like the
FileSystemWatchercomponent that doesn't work on Windows), they rely on underlying system components like Windows Common Controls. Differences in the system there can make a little difference, though not as drastic as what you described with the positionedButton. When it comes to positioning, the most common culprit is the DPI (dots per inch, sometimes refered to as PPI or pixels per inch). The difference in DPI affects how elements are positioned. As much as I hate VB (version 6 and below), it did get this right; it used twips, which is a logical unit (i.e., inches, points, centimeters, etc.). .NET uses pixels. If you search the C# forum, you'll find several threads where I've posted more information about this including a snippet of code I use when necessary. Other differences in behavior could be because you're using a debug build where another machine is using the release build. Debug builds are typically slower (not always true, but most often true). It could also be because you have some APIs (native functions, COM libraries, etc.) that you're P/Invoking or RCW'ing (it's a verb now, I say! :)) that others don't have. Keep in mind when you deploy RCWs (interop assemblies), the corresponding COM libraries must be present as well (not necessarily the same version, but a version of the typelib and implementing COM server that uses the same CLSIDs and IIDs, assuming the COM server is written correctly). For all these reasons, that's why companies test in large test bays with a multitude of different hardware and software configurations. Also, before some *nix zealot jumps in and says "switch to linux", the same is true for linux and other *nix flavors as well. *nix solves DLL hell by using symbolic links but still requires that a library to which an executable was bound be installed on the platform.Microsoft MVP, Visual C# My Articles
-
First off, please don't address me personally. I'm flattered, but it's not very nice to others with good answers like Nick and Dave and others that show up from time to time. Second, keep in mind that the .NET Framework - while the same on all Windows platforms (save the differences between Windows and Windows NT, like the
FileSystemWatchercomponent that doesn't work on Windows), they rely on underlying system components like Windows Common Controls. Differences in the system there can make a little difference, though not as drastic as what you described with the positionedButton. When it comes to positioning, the most common culprit is the DPI (dots per inch, sometimes refered to as PPI or pixels per inch). The difference in DPI affects how elements are positioned. As much as I hate VB (version 6 and below), it did get this right; it used twips, which is a logical unit (i.e., inches, points, centimeters, etc.). .NET uses pixels. If you search the C# forum, you'll find several threads where I've posted more information about this including a snippet of code I use when necessary. Other differences in behavior could be because you're using a debug build where another machine is using the release build. Debug builds are typically slower (not always true, but most often true). It could also be because you have some APIs (native functions, COM libraries, etc.) that you're P/Invoking or RCW'ing (it's a verb now, I say! :)) that others don't have. Keep in mind when you deploy RCWs (interop assemblies), the corresponding COM libraries must be present as well (not necessarily the same version, but a version of the typelib and implementing COM server that uses the same CLSIDs and IIDs, assuming the COM server is written correctly). For all these reasons, that's why companies test in large test bays with a multitude of different hardware and software configurations. Also, before some *nix zealot jumps in and says "switch to linux", the same is true for linux and other *nix flavors as well. *nix solves DLL hell by using symbolic links but still requires that a library to which an executable was bound be installed on the platform.Microsoft MVP, Visual C# My Articles
Thanks, I'll look into these causes and hopefully find the reasons. I didn't mean to exclude anybody else, I just couldn't think of any other VIP names right offhand. I wanted a straightforward, and knowledgeable answer on this question, and I knew I'd get it if you answered. I appreciate the help! - D