I am trying to de-serialize a XML string back to an object. The code does NOT have a reference to the assembly that has the class definition. We keep the fully qualified name in the XML document using XmlTextWriter.WriteProcessingInstruction, so we use that to get the type at runtime.
GetType( fullyQualifiedAssemblyName, false, true );
This of course works perfectly on the full framework.
The reason is because the ignoreCase #3 parameter cannot be true in the compact framework. Apparently case insensitive searching is not supported in the Compact Framework. Turning on the throwOnError option in parameter 2 helped me identify the problem.
I don't see any documentation that describes this behavior so I thought I would post it here.
Related
After doing the general upgrade steps for the migration. My razor had 100's of errors suddenly after removing Microsoft.AspNetCore.All. These error were not consistent, these were general compiler errors.
Some combination of
IDE1007 C# The name does not exist in the current context.
CS0111 C# Type already defines a member called with the same parameter types
CS0538 C# in explicit interface declaration is not an interface
CS0116 C# A namespace cannot directly contain members such as fields
or methods
CS8107 C# Feature is not available in C# 7.0. Please use
language version 9.0 or greater.
Just all over the place stuff, and this was all working perfectly in 2.2
I was able to fix this. What I found was that we had few places in the code where we were using # inside a razor block, this used to work fine but breaks in core 3.1. I am assuming that the process of generating the classes by Razor SDK was failing because I was also getting errors in index.g.cshtml.cs.
We probably had this issue in 5 files at most but we were getting 500+ build errors. Very frustrating, so adding this answer because I was not able to find any similar answer anywhere.
Example of bad code, notice the extra # inside {}.
#{ var replacements = new string[] { #Model.TotalItemsInCart.ToString() };}
I'm debugging a rather large VB.net script in Rider. Several Dictionary and List objects are constructed and I want to inspect them in the Debugger using Evaluate Expression and query them using Linq functions like Select and Where.
In JetBrains Rider, setting a breakpoint and opening Evaluate Expression, I can view the objects but when trying to run any function on them, all I get is messages like these:
Expression:
GroupedProducts.Where(p => p.Key == "1234567").ToList()
Result:
'Dictionary<string, string>' does not contain a definition for 'Where' and no accessible extension method 'Where' accepting a first argument of type 'Dictionary<string, string>' could be found (are you missing a using directive or an assembly reference?)
Here, the GroupedProducts object is of type Dictionary<string, string> but the autocomplete suggestions in Evaluate Expression only seem to pickup methods of Object.
Is there something I'm missing? I've set JetBrains as the default debugger but that didn't help anything. Any suggestion is welcome.
.Net SDK: .Net Framework v4.7 developer pack
Rider version: 2019.3.1
OS: Windows 10 Professional
I faced the same problem, but sometimes the expressions were still evaluated!
Try using Enumerable.Where(GroupedProducts, predicate) instead of GroupedProducts.Where(predicate) in "Evaluate" window.
I'm trying to follow the promising suggestion posted here to try StatePrinter as a shortcut to rolling my own ToString methods. I agree with the OP that it is a shame that VS still can't generate this method for me.
I've got a fairly large project, in VS2015 (Community Edition), with both VB and C# code. I added the current stable version of StatePrinter using NuGet.
I can make the example code from the SO answer work fine in my C# code but when I do what I think is the equivalent in my VB code:
Private Shared sp As StatePrinter.Stateprinter = New StatePrinter.Stateprinter
Public Overrides Function ToString() As String
Return sp.PrintObject(Me)
End Function
I just get the compiler error
'Stateprinter' is ambiguous in the namespace 'StatePrinter'
There IS another constructor, StatePrinter (note difference in capitalization only) which is deprecated and, in any case, generates the same error message.
I'm led to the unfortunate conclusions that
VB in VS2015 is acting as if it is case insensitive. Can that be true?
No one else is using StatePrinter from VB.
Can anyone provide any suggestions on how to use StatePrinter from VB? I'm willing to believe I'm making some rather brain-dead mistake in converting the C# example to VB.
It is near impossible to use this directly in VB and get around the ambiguous name issue. You could write a class library wrapper in C# that doesn't expose this mismatch (that is, it has an internal StatePrinter object and exposes constructors that are PascalCased the same.
Another option would be to use reflection in the VB project to get around the case insensitivity.
You could also create a GitHub issue. Or, be a contributor to the project and create a suggested fix for it. :)
As soon as I got done writing #1 in the question above, I was able to figure out how to search for the answer to that bit.
Yes, VB is case insensitive, at least, as far as it needs to be in this case:
See the rather nice writeup here:
https://stackoverflow.com/a/2301980/165164
So, we're left with the rather plaintive: is no one else using StatePrinter from VB?
I'm making the transition from VB6 to VB.Net (VS 2010) and have a basic rather than expansive understanding of the latter. I obviously have quite a bit of code to... I hesitate to use the word "upgrade" when "port" would be more apt given that the upgrade wizard in past versions of VS may as well have just commented out the code and said "Hey, why don't you re-start from scratch?"
In one procedure which I'm bringing across the Len() function was used to determine the length of a string variable. That still works in VB.Net (though I imagine that it's actually a call to the Strings.Len Method), but the other alternative is to just query the .Length property of the variable.
The question is which to use and why. I've looked through the relevant MSDN pages and all they seem to tell me is that the method/property exists. Nothing is said about performance issues, particularly when loops of large numbers of calls might be involved.
My question, then, is whether anyone is aware of any tested and confirmed benefit of using one approach over the other, or whether it's merely a question of personal preference. Any pointers on similar situations that I might encounter as I make the progression would also be appreciated though given the Stack Overflow guidelines it's just this one issue that I'm interested in seeing whether there's a specific answer to.
Because you're using VB.NET, your Strings can be Nothing and unless you explicitly check for that, most VB methods, including Len, will treat it the same as String.Empty i.e. "".
With Reflector you can see Len is implemented as a null check, returning 0 for Nothing and otherwise returning .Length, and the JITter will likely in-line the call.
So, if you're using other VB methods, I'd suggest using Len too, unless you know the String is not Nothing or check for Nothing everywhere.
So according to this:
Len, another classic BASIC function, returns the length of a string. System.String has the Length property that provides the same information. Is one better than the other?
Performance-wise, these two functions show little difference over 1000’s of iterations. There doesn’t appear to be any reason to prefer one over the other in this case plus there is no functional difference. I’m kind of partial to using the property value rather than the VB function since it encourages thinking of .NET strings as objects. However, at the core, it’s really only a personal preference thing.
If you trust their word, then there's your answer. Otherwise, coding up a test and iterating should give you the final answer.
I'm not sure about the specifics of the Len() method (my language of choice is C#), but I would say definitely go with the Length property. Length is a member of the System.String class, whereas Len() isn't.
My guess is that Len() is just a VB shim on top of the Length property. Someone could probably make the argument that using Len() is more idiomatic, from a VB point of view. I think I'd prefer to use the property built in to the class, rather than just use a different mechanism just because it's provided by the language.
The Len method is provided for backwards compatibility with old VB6 (and earlier) non-.NET code. There's nothing technically wrong with using it. It will work, and just as well, at that. But, it's better to use the new .NET way of doing things whenever possible. Outside of getting you more into the ".NET mindset", though, the only real tangible benefit of using String.Length is that it makes it easier to port the code to other .NET languages in the future.
In addition to #Andrew's post, the Len() is string function from Visual Basic run-time library where as Length is a property of System.String class of .net framework API.
Recently I faced problem with my old VB.Net code that was using Len() function. I upgraded my project to Core which was referencing the old VB.net dll file and it was using Len() function. I got run time compatibility error - Method not found: 'Int32 Microsoft.VisualBasic.Strings.Len(System.String)'
I have to change all such old function that Core has deprecated. So I stand by using String.Length over Len() as suggested by Steven Doggart.
I am calling the OTA API from HP Quality Centre and one of the calls requires sending a NULL.
This is the actual line of code:
stepF.AddItem(NULL)
This works perfectly in VBA and VB6 but VB.NET doesn't accept Nulls. Anyone know how to fix such an issue?
You need to use Nothing, which is mostly equivalent to null.
Nothing is the Null value for most reference types in VB.Net, I would recommend taking a look at Nullable(Of T) on either MSDN or some good information about it in this SO post, if the API you are using is a .Net web service you may be able to partial class the WSDL and fix although it sounds as though you are not.
The correct value to use is System.DBNull.Value.
Even if the documentation tells us that this is generally used for database null values, it represent the absence of value, otherwise NULL.
You should use DBNull