Develop Reference

Export to Excel spreadsheet in Cross Platform C# .NET app

So I'm writing a cross platform app that will run on Mac, Linux, and Windows. I need a library that can export to a .xlsx without having to have Excel installed on the host computer. Also, I will need to include simple formulas in the spreadsheet. I'm brand new to .NET so I don't know which version of .NET Core the library should be compatible with in order for the app to be cross platform capable. I've heard of ClosedXML which looks perfect for what I'm trying to do. But absolutely no where on the NuGet page nor on their GitHub page does it state whether it's compatible with .NET Core or cross-platform, etc. Please help! I've written whole programs before only to find out I've written it with the completely wrong tools.

You can try my SwiftExcel library. Besides that it is cross platform (if you install it into your .NET Core application), this library is also very efficient as it writes directly to the file. For example you can write 100k rows in few seconds without any memory usage.
Here is a simple example of usage:
using (var ew = new ExcelWriter("C:\\temp\\test.xlsx"))
{
for (var row = 1; row <= 10; row++)
{
for (var col = 1; col <= 5; col++)
{
ew.Write($"row:{row}-col:{col}", col, row);
}
}
}
You can also use some basic formulas like Count, Max, Sum or Average. Here is an example from the same GitHub page:
using (var ew = new ExcelWriter("C:\\temp\\test.xlsx"))
{
for (var row = 1; row <= 20; row++)
{
ew.Write(row.ToString(), 1, row, DataType.Number);
}
ew.WriteFormula(FormulaType.Average, 1, 22, 1, 1, 20);
ew.WriteFormula(FormulaType.Count, 1, 23, 1, 1, 20);
ew.WriteFormula(FormulaType.Max, 1, 24, 1, 1, 20);
ew.WriteFormula(FormulaType.Sum, 1, 25, 1, 1, 20);
}

When confronted with this, I start with a simple proof of concept application. In your case that would be: Create an .xls file with just a single entry. With such a simple project, it's easy to try out several libraries quickly.
Start by creating a .NET core project, then import a nuget package and see if it still compiles. If it does, great, try and let it run on android instead of windows. If it still runs, great. Now you can start writing the first lines of code where you use the library. Just try to create a .xls with a simple entry. Try it on windows, android. If that works test out if the library has all the functionality you need.
If all that passes you've got something that's probably going to work.
Divide and conquer, always go step by step.

How to use OpenHardwareMonitor .dll?

I'm trying to get status data of my processor on the local machine. I found several tutorials online, but no one of them covers the error I'm getting.
This is my code:
UpdateVisitor visitor = new UpdateVisitor();
Computer computer = new Computer();
computer.Open();
computer.CPUEnabled = true;
computer.Accept(visitor);
It throws an Exception when calling computer.Open() and this is the exception message:
What am i doing wrong? If i can provide some more detail, please let me know.
I'm referencing the library in a .NET Standard 2.0 project.

Solved the problem by referencing the library in a .NET Framework 4.7.1 project, instead that in a .NET Standard 2.0 project. I post this answer just to warn other people trying to achieve this that this library is not fully compatible with .NET Standard code.

I stole this WMI Answer from this question: C# CPU and GPU Temp.
Just install System.Management and start VS in Admin mode, and you can access the sensors.
using System;
using System.Diagnostics;
using System.Management;
class Program
{
static void Main(string[] args)
{
Double CPUtprt = 0;
System.Management.ManagementObjectSearcher mos = new System.Management.ManagementObjectSearcher(#"root\WMI", "Select * From MSAcpi_ThermalZoneTemperature");
foreach (System.Management.ManagementObject mo in mos.Get())
{
CPUtprt = Convert.ToDouble(Convert.ToDouble(mo.GetPropertyValue("CurrentTemperature").ToString()) - 2732) / 10;
Console.WriteLine("CPU temp : " + CPUtprt.ToString() + " °C");
}
}
}

Creating an instance of the REngine using R.Net version 1.5.5

I am trying to create a "Hello World" example in R Language using R.Net version 1.5.5 (loaded from NuGet). Unfortunately, none of the online samples that I have seen work.
THIS IS WHAT I HAVE DONE:
Installed Microsoft R Open 3.2.4, the enhanced R distribution
Installed R Tools for Visual Studio (R version 3.2.4 (2016-03-16))
Created an R Project & tested a simple script
Created an MVC application & referenced R.Net version 1.5.5 from NuGet
MY PROBLEM:
All of the online examples I have seen must be using an earlier version because I cannot create an instance of the REngine for the LIFE of me! In fact, I keep getting:
Dll was not found
...yet C:\Program Files\Microsoft\MRO\R-3.2.4\bin\x64\r.dll does indeed exist.
Q: How do I create an instance of the REngine using R.Net version 1.5.5?
MY CODE LOOKS LIKE:
class Program
{
#region <Methods>
static void Main(string[] args)
{
SetupPath(); // current process, soon to be deprecated
using (REngine engine = REngine.CreateInstance("RDotNet"))
{
engine.Initialize(); // required since v1.5
CharacterVector charVec = engine.CreateCharacterVector(new[] {"Hello, R world!, .NET speaking" });
engine.SetSymbol("greetings", charVec);
engine.Evaluate("str(greetings)"); // print out in the console
string[] a = engine.Evaluate("'Hi there .NET, from the R engine'").AsCharacter().ToArray();
Console.WriteLine("R answered: '{0}'", a[0]);
}
Console.WriteLine("Press any key to exit the program");
Console.ReadKey();
}
public static void SetupPath()
{
var oldPath = System.Environment.GetEnvironmentVariable("PATH");
var rPath = #"C:\Program Files\Microsoft\MRO\R-3.2.4\bin\x64";
if (!Directory.Exists(rPath))
throw new DirectoryNotFoundException(string.Format(" R.dll not found in : {0}", rPath));
var newPath = string.Format("{0}{1}{2}", rPath, System.IO.Path.PathSeparator, oldPath);
System.Environment.SetEnvironmentVariable("PATH", newPath);
}
#endregion
}

I hate to answer my own question, but here it is...
The Microsoft R Open 3.2.4 enhanced R distribution installs x64 files. As such, running under ANY CPU will cause a failure because it will choose x86 (by default).
Under
Project Properties -> Build: in the "General" section
Choose x64 as your Platform Target

Visual Studio 2015 has problems communicating using VISA Libraries

I'm having problems with the VISA-Com Libraries to communicate with a Keysight (N6700B) power supply.
I have some C# code I am compiling in Visual Studio 2015, and it does not work. However, if I compile the same code in Visual Studio 2012, then it works.
Basically I am just doing simple communication with the device:
using Ivi.Visa.Interop;
//...
string address = "USB0::2391::2311::MY54002380::0::INSTR";
ResourceManager rm = new ResourceManager();
FormattedIO488 myDmm = (IMessage)rm.Open(address , AccessMode.NO_LOCK, 2000, "");
myDmm.WriteString("*RST"); // reset the device
myDmm.WriteString("*IDN?"); // request the IDN string;
string IDN = myDmm.ReadString(); // This is where it fails, returning: "VI_ERROR_TMO: A timeout occurred"
Also, the power supply has an error state of: "Error -420, Query UNTERMINATED"
The code does not work with VS2015, but it DOES work with VS2012.
(In VS2012 I get no errors at all.)
I have tried downloading the latest drivers from KeySight, and it still does not work (www.keysight.com/find/iosuitedownload).
Does anyone have any idea why it would be breaking with VS2015 but work with VS2012?
I've looked up "Quere Unterminated" and some say that it could be a missing Termination character "\n". I've tried adding the "\n" to both writeStrings, and it still fails.
EDIT: I have also now tried using (in various places):
myDmm.IO.TerminationCharacterEnabled = true; // and = false
myDmm.FlushWrite(); // also tried passing in "true" (default is 'false')
I also tried adding the:
myDmm.IO.TerminationCharacter
to the WriteStrings.

http://download.ni.com/support/softlib//visa/NI-VISA/15.0/Windows/readme.html
Microsoft Visual Studio Support
The following table lists the programming languages and Microsoft Visual Studio versions supported by this version of NI-VISA.
Earlier versions of NI-VISA support other application software and language versions. For more information on Visual Studio compatibility with earlier versions of VISA, refer to ni.com/info and enter the info code NETlegacydrivers. To find and download an earlier version of a driver, refer to ni.com/downloads.
Visual Studio Versions Support by NI-VISA:
Visual C++ MFC1 -------------- 2008
Framework 3.5 Languages (Visual C# and Visual Basic .NET) -- 2008
.NET Framework 4.0 Languages (Visual C# and Visual Basic .NET)-- 2010
.NET Framework 4.5 Languages (Visual C# and Visual Basic .NET)-- 2012
So apparently the drivers don't work with VS2015... (not sure how a newer version doesn't work.. but okay)
EDIT, FOUND ANSWER
Someone from NI-VISTA told me to just add "true" as a second parameter:
myDmm.WriteString("*RST",true); // reset the device
myDmm.WriteString("*IDN?",true); // request the IDN string;
string IDN = myDmm.ReadString(); // now it works.
I'm not sure why "true" wasn't needed in 2012, and why it is needed in 2015... oh well.

I confirm: the method WriteString() (but not only this) needs the bool parameter flushAndEND = true (default value = false) in order to complete the command. Without it, the instrument can't parse the instruction. If you send multiple commands, the instrument can't separate and identify them.
I suggest you to use the Keysight IO monitor for sniffing the communication between your instruments and you controller (PC?) . It's an utility of the IO Libraries Suite (v17.1).
For details, see the attached IFormattedIO488 interface definition, belonging to the reference Ivi.Visa.Interop.
using System.Runtime.InteropServices;
namespace Ivi.Visa.Interop
{
[...]
public interface IFormattedIO488
{
[DispId(1610678274)]
bool InstrumentBigEndian { get; set; }
[DispId(1610678272)]
IMessage IO { get; set; }
void FlushRead();
void FlushWrite(bool sendEND = false);
dynamic ReadIEEEBlock(IEEEBinaryType type, bool seekToBlock = false, bool flushToEND = false);
dynamic ReadList(IEEEASCIIType type = IEEEASCIIType.ASCIIType_Any, string listSeperator = ",;");
dynamic ReadNumber(IEEEASCIIType type = IEEEASCIIType.ASCIIType_Any, bool flushToEND = false);
string ReadString();
void SetBufferSize(BufferMask mask, int size);
void WriteIEEEBlock(string Command, object data, bool flushAndEND = false);
void WriteList(ref object data, IEEEASCIIType type = IEEEASCIIType.ASCIIType_Any, string listSeperator = ",", bool flushAndEND = false);
void WriteNumber(object data, IEEEASCIIType type = IEEEASCIIType.ASCIIType_Any, bool flushAndEND = false);
void WriteString(string data, bool flushAndEND = false);
}
}

Have you tried the ReadBytes method? This method reads a fixed amount of bytes from the device. The error you've encountered most probably occurs because the the visa driver tries to read data until a termination character, which you never explicitly set, is received.
Try setting the TerminationCharacter Property to either \n or \r (depending on the instrument) and it should work. Furthermore, you might want to add it to the commands you send as well so the instrument won't bother you with this error (-420) anymore.

Future-proofing the .NET version detection

Not to beat the dead horse, however, I am looking for a way to detect the installed .NET frameworks. It seems like the provided solutions (in the links) are all good up until the point a new version of the framework is released and then all bets are off. The reason for this is that the detection relies on the registry keys and it seems that v4 of the framework has broken the convention and one now has to take extra steps to detect v4.
Is there a way to detect the .NET framework that will also work when .NET v5 appears.
EDIT: Ok, for future generations of frustrated .NET Version seekers, here is the code to make it happen:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Text.RegularExpressions;
using System.Diagnostics;
using Microsoft.Win32;
private List<string> GetInstalledDotNetFrameworks()
{
string key = string.Empty;
string version = string.Empty;
List<string> frameworks = new List<string>();
var matches = Registry.LocalMachine
.OpenSubKey(#"SOFTWARE\Microsoft\NET Framework Setup\NDP")
.GetSubKeyNames().Where(keyname => Regex.IsMatch(keyname, #"^v\d"));
// special handling for v4.0 (deprecated) and v4 (has subkeys with info)
foreach (var item in matches)
{
switch (item)
{
case "v4.0": // deprecated - ignore
break;
case "v4":// get more info from subkeys
key = #"SOFTWARE\Microsoft\NET Framework Setup\NDP\" + item;
string[] subkeys = Registry.LocalMachine
.OpenSubKey(key)
.GetSubKeyNames();
foreach (var subkey in subkeys)
{
key = #"SOFTWARE\Microsoft\NET Framework Setup\NDP\" + item + #"\" + subkey;
version = Registry.LocalMachine
.OpenSubKey(key)
.GetValue("Version").ToString();
version = string.Format("{0} ({1})", version, subkey);
frameworks.Add(version);
}
break;
case "v1.1.4322": // special case, as the framework does not follow convention
frameworks.Add(item);
break;
default:
try
{
// get the Version value
key = #"SOFTWARE\Microsoft\NET Framework Setup\NDP\" + item;
version = Registry.LocalMachine
.OpenSubKey(key)
.GetValue("Version").ToString();
frameworks.Add(version);
}
catch
{
// most likely new .NET Framework got introduced and broke the convention
}
break;
}
}
// sort the list, just in case the registry was not sorted
frameworks.Sort();
return frameworks;
}

In short, you can use this approximately (see below for more complete solution):
Microsoft.Win32.Registry.LocalMachine
.OpenSubKey(#"SOFTWARE\Microsoft\NET Framework Setup\NDP")
.GetSubKeyNames().Where(keyname=>Regex.IsMatch(keyname,#"^v\d"))
On my machine, this returns: v2.0.50727, v3.0, v3.5, v4, v4.0. Subkeys could be used to detect service packs (which are probably relevant). Also, using the key SOFTWARE\Microsoft\.NETFramework returns v2.0.50727, v3.0 and v4.0.30319 - ehhh, lovely, slightly different!
There's no guarantee this pattern will hold, but it's a pretty reasonable bet :-). http://support.microsoft.com/kb/318785 has some more info on the details of the registry describing the versioning, and in particular, you may need to check for Install - but that's tricky as v4.0 demonstrates.
Edit: I've extended this to detect arbitrary sub-key's of the registry that include installation info so as to detect v4 Client and Full profiles correctly. Also, the RegistryKey type is IDisposable, and it looks like the Dispose method is indeed doing something (registry key unlocking).
var versionList = new List<string>();
using(var ndpKey=Registry.LocalMachine.OpenSubKey(#"SOFTWARE\Microsoft\NET Framework Setup\NDP")) {
Action<RegistryKey, Action<RegistryKey,string>> processKids = (node, action) => {
foreach(var childname in node.GetSubKeyNames())
using(var child = node.OpenSubKey(childname))
action(child,childname);
};
Action<RegistryKey, Func<RegistryKey, bool>> visitDescendants = null;
visitDescendants = (regkey, isDone) => {
if(!isDone(regkey))
processKids(regkey, (subkey, subkeyname)=>visitDescendants(subkey,isDone));
};
processKids(ndpKey, (versionKey, versionKeyName) => {
if(Regex.IsMatch(versionKeyName,#"^v\d")) {
visitDescendants(versionKey, key => {
bool isInstallationNode = Equals(key.GetValue("Install"), 1) && key.GetValue("Version") != null;
if(isInstallationNode)
versionList.Add(
key.Name.Substring(ndpKey.Name.Length+1)
+ (key.GetValue("SP")!=null ? ", service pack "+ key.GetValue("SP"):"")
+ " ("+key.GetValue("Version") +") "
);
return isInstallationNode;
});
}
});
}
versionList then contains:
v2.0.50727, service pack 2 (2.0.50727.4927)
v3.0, service pack 2 (3.0.30729.4926)
v3.5, service pack 1 (3.5.30729.4926)
v4\Client (4.0.30319)
v4\Full (4.0.30319)

Do you expect we can tell you the future? :) Why do you need that in the first place? I mean, if you write an app for v4, what difference does it make if v5 is installed or not? You can specify in the app.config what versions you support, but you can't know in advance what the next version will be, or even if your app will run on that. Whenever a new framework comes out, you'll have to test your app, and decide if you want to migrate or not. If you migrate, then you make changes to the app.config and possibly the code, too, and release a new version. If you don't, then you'll still require that an older framework version be installed. It's not like v5 comes out and people will start uninstalling all the previous frameworks. I still have v1.1 and v2 on my machine and I guess they'll stick around for a while.

I am in agreement with fejesjoco. Why do you even want to detect a future version that your code has not been compiled against?
If you look in the Framework folder (C:\Windows\Microsoft.NET\Framework) you will see that all previous versions of the Framework are install along with the most recent version. If your code is compiled against 4.0 and 5.0 comes out it will still have a folder for 4.0.
If you could give us a bit more context as to why you want to detect future versions we may be able to help you better.

Include an auto-update feature in the detection tool?