Our team upgraded a large project developed using Visual Studio 2010 to Visual Studio 2019.
One of the team members uses the String.Format(String, Object[]) and passes an array of objects to the method while the rest of the team uses the String.Format method by passing the objects as individual arguments.
This was just a matter of style preference when developing in Visual Studio 2010; but in Visual Studio 2019, any place that uses the String.Format(String, Object[]) that is passed an array is causing IDE warnings to appear.
Since the project is large, the number of these bogus warnings is numerous and going through the code to "fix" something that isn't broken is not preferable; however, these warnings do hide cases where the String format incorrectly matches the parameters (causing a runtime error).
Stranger yet, there are cases where these lines of code actually do throw String.Format exceptions if the machine running the application is not using .NET Framework 4.8. This doesn't make sense to me because this version of the String.Format method has been around since WELL before 4.8.
Here is an example of what I'm talking about.
Notice how there are 2 warnings on line 9 about the number of arguments passed to the String.Format method not matching the number expected in the format.
While on line 12 there are no warnings: because the String.Format method is being passed individual argument parameters instead of an array.
Does anyone have any insight into why this is causing problems using Visual Studio 2019 with .NET Version 4.8? Or have a suggestion on how to correct this problem (preferably one that doesn't require modifying every line of code the one team member used their style of calling the String.Format method).
Edit:
Update, upon playing with this a bit more, I discovered that if the array is not declared inline (it is declared before hand), there are no errors. This worked when passing an array of strings and an array of objects.
This just makes the IDE warning even more bizarre....
Related
what’s “tabs are not allowed in f# code unless the #indent off option is used” Error?
I use the last version .netcore and vs 2019. I want to use the lightweight syntax
When using lightweight syntax, you must use spaces, not tabs, for indentation.
Most editors have an option (including Visual Studio, by default) will turn a tab into spaces automatically when you type. I suspect this was written in a different editor and opened in VS.
In Visual Studio 2019, if you select everything in your document, and do Edit->Advanced->Untabify Selected Lines, it will correct it for you, as well.
I've been using ESENT for my projects quite extensively and I really love how easy and fast it works. And stable too!!
But I have a HUGE problem with Windows 8!!! Regardless of how I link to the esent.dll (dynamically or statically) whenever I call something other than JetSetSystemParameter, the dll is crashing, takig my app down the cliff.
Unfortunately I still can't get it running. My code had no problem running with Windows 7 or older. But with Windows 8 I get esent.dll crashing when I try to create an instance (floating point invalid operation).
I tried all possible calling conventions. This is definitely NOT the problem. I tried some more and discovered this weird situation: 1. I created a demo application using VS 2012 and JetCreateInstance worked just fine. 2. Exactly the same code in Delphi XE3 will send esent.dll crashing. 3. I created a DLL using VS 2012, exporting the method that worked perfectly in the above demo app, thinking it's a Delphi bug. 4. And then I loaded the DLL in a demo Delphi project (tried with 6, XE2 and XE3). Called the method and BOOM. Same crash.
Now my assumption is that Microsoft won't allow?!? any other developer environment to work correctly with the esent.dll. Is this possible???
The error, a floating point invalid operation, makes the problem sound as though it is related to the floating point control word.
By default Delphi unmasks floating point exceptions. So when code asks the floating point unit to perform operations that result in errors, the FPU signals which is then converted to an exception.
But most other Windows development environments mask these exceptions on the FPU. Such code is written under the assumption that the execution environment has FPU exceptions masked. But if you call a DLL from Delphi, the execution environment will have unmasked FPU exceptions, breaking that assumption. I suspect that if you mask FPU exceptions then your problems will disappear.
To test if this is the problem, you can simply add this to your code, executed early in its life:
Set8087CW($027F);
This will mask all exceptions and set the FPU control word to the default Windows setting.
In the longer term you may wish to mask exceptions before each call to this DLL, and then restore the FPU control word when the call to the DLL returns.
That is a slightly dangerous game using the libraries that are supplied with Delphi since Set8087CW is not threadsafe due to its use of the global variable Default8087CW. If you wish to read more about that issue, I refer you to QC#107411.
I've used F# to do some quick data-analysis using datastructures from another project. To do so, it needs access to this project; i.e. it needs an assembly reference - but the project is an executable.
I've tried this in F# interactive, and it almost works*; I can #I the appropriate path and #r the executable and a few support dll's - but I can't actually use em. And whatever I do, I can't get the reference into a compiled F# program: VS lets me add a reference just fine, and the appropriate compiler option -r:X:full\path\here.exe is correctly generated by the project, but none of the datastructures are present and the compiler complains of non-existent namespaces; it's as if the reference didn't exist. The application is 64-bit, which may be relevant. 64-bit dll's work fine.
(*) after setting fsi.exe to run in 64-bit mode it thinks it can load it, but actually using it returns FS0193: internal error.
How can I reference a managed 64-bit executable from an F# project?
To others with this same issue: as a workaround, I'm now compiling the executable as Any CPU (which will be executed in 64-bit mode, so behaves the same). This allows FSI and the compiler to reference it. Based on the questions referenced in the comments, this seems to be a known bug that will hopefully be fixed some day.
I have a 3rd party .dll that I have successfully added as a reference in both a VS 2010 C# project and an F# VS 2010 project. I can view the contents in the object browser in both cases, but the F# version won't let me "open" the library. It works fine in the C# project (with the "using" directive), and I can write a program that uses the contents of this particular .dll. I have not had any trouble with other .dlls in F#/VS 2010/.NET 4.0 on Windows 7.
Any ideas as to why this might be happening? Or how I could debug this further?
See what the csc.exe and fsc.exe command-lines have for the library in question (in VS, open the 'Output Window' after a rebuild), to see if they both have the same reference (e.g. -r:Path\Library.dll).
And to be clear, you're saying
open NagLibrary
in F# yields the error message in the title, but
using NagLibrary;
in C# works and opens the namespace?
make sure you reference the path within the script using the double "\" convention
for me this worked
#r "C:\homeware\\blp\\api\\APIv3\\DotnetAPI\\v3.4.5.4\\lib\\Bloomberglp.Blpapi.dll"
open Bloomberglp.Blpapi
I'm trying to use the Seq.generate_using function but unfortunately, I don't seem to be able to find it. I thought it would be living here:
Microsoft.FSharp.Collections.Seq.generate_using
But it doesn't. I am getting the error listed below.
C:\Users\Owner\Documents\Visual Studio
2008\Projects\fsharp1\Program.fs(54,63):
error FS0039: The value, constructor,
namespace or type 'generate_using' is
not defined. A construct with this
name was found in
FSharp.PowerPack.dll, which contains
some modules and types that were
implicitly referenced in some previous
versions of F#. You may need to add an
explicit reference to this DLL in
order to compile this code.
According to the Sept 2008 CTP Release Notes:
The F# library is split into two
components. FSharp.Core.dll: Contains
the core F# libraries, which will be
stabilized and versioned infrequently.
FSharp.PowerPack.dll: Contains
additional useful F# libraries and
tools which will version more
frequently, and allow continued
innovation on top of the core F#
language and libraries.
Some methods in the Seq module were moved into the FSharp.PowerPack assembly, so you can only get those methods by doing the following:
If you're using Visual Studio, open your Solution Explorer, right-click on the project file, choose "Add Reference", and add "FSharp.PowerPack.dll".
If you're using a script file or fsi, then type #r "FSharp.PowerPack";; to load the assembly.
Now you should be able to call Seq.generate_using.
The #r "FSharp.PowerPack";; works for me but the addition of PowerPack to my solution does not. I am trying to use HashSet<>.