I can't seem to configure my CustomDictionary.xml correctly to address a couple of Code Analysis warnings I am getting in Visual Studio 2010.
The first is a namespace "Mvc" - just like the Microsoft provided namespace. I get:
CA1704: Microsoft.Naming: "Correct the spelling of 'Mvc' in namespace name 'xyz.Mvc.abc'
I've tried putting 'Mvc' in the acronyms section of the CustomDictionary like:
<Acronyms>
<CasingExceptions>
<Acronym>Mvc</Acronym>
</CasingExceptions>
</Acronyms>
The warnings still appear. So, I tried putting an entry in the DiscreteExceptions node under the Words element - still nothing.
How can I properly tell CA that "Mvc" is correct?!?!
Btw, the same issue exists with an acronym representing a business unit within the company.
Secondly, I have the term "CheckOut" used in the code. It parallels a "CheckIn" method so I want it cased as I've indicated. CA says that the compound word should be cased "Checkout" and regardless where I put the entry in the CustomDictionary file, I still get the warning. How do I deal with this one?
Note: I do have the Build Action for the file set to CodeAnalysisDictionary and other terms are registering correctly. For some reasons, nothing I do seems to address these three.
You need to add the term to the recognized words section, not the casing exceptions section. e.g.:
<Dictionary>
<Words>
<Recognized>
<Word>mvc</Word>
</Recognized>
</Words>
</Dictionary>
Related
I'm trying to debug a program in Visual Studio for which I have the symbols, but not the source code (it's a Unity game, the source in question is for the UnityPlayer.dll. I do have the source for the actual exe file).
The symbols load correctly, I can break into the debugger and can see call stacks with function names, as I expect to.
However, when I try to add a function breakpoint, it does not work: the breakpoint gets added, but it shows a little error icon in the Breakpoint window, and it's never hit.
If I double-click on a stack frame, I can get to the disassembly window, and the "Address" bar correctly shows the function name. However, if I try to enter any symbol name in the bar - including just copying the one it's already showing - I get an error message saying "identifier "whatever" is undefined". It's as if some part of Visual Studio is not aware of the loaded symbols.
One suspicious thing I noticed is that in the call stack window, all frames not in the actual exe file are shown with the "Unknown" language. I have no idea what is causing this.
Here's a picture to hopefully make this a little clearer:
What can I do to fix this, or at least work around the issue somehow? I've encountered this on VS 2017 and tried updating it to the latest version, and installing VS 2019, but nothing helped.
Notice in the names it's showing you, you get the parameter types too. Like, it's showing you FMOD_OS_Time_Sleep(unsigned int) and not just FMOD_OS_Time_Sleep. This is because the name is mangled, random looking characters are added on either side of the name to encode how many parameters it takes, and what types those parameters are.
One possibility is that it's expecting you to put in the mangled representation of the name. You can also try putting in the name exactly as it appears in the call stack, I would try both with UnityPlayer.dll! and without. Failing that, run strings on the dll to get the mangled representation of the function name and try that.
I'm working on a Xamarin Forms app, using a .NET Standard library. I've used the TranslateExtension as mentioned in the docs. I've added three resource files:
AppResources.resx (with matching code-behind file, auto-generated)
AppResources.nl.resx (Dutch translations)
AppResources.fr.resx (English tranlations)
When debugging the (UWP) app, I can't get the default culture (English) to be displayed. The following line returns null:
ResMgr.Value.GetString(Text, ci);
I've add some lines for debugging, and the other two languages do return the translated value:
ResMgr.Value.GetString(Text, new CultureInfo("nl")); // OK
ResMgr.Value.GetString(Text, new CultureInfo("fr")); // OK
ResMgr.Value.GetString(Text, new CultureInfo("en")); // returns null
What could possibly be the cause of this?
Things I've tried:
I've copy-pasted the key across all resource files, so I've ruled out misspelling the resource key.
I've tested "en-GB", "en-US", CultureInfo.InvariantCulture.
I've changed the default lanuage in the appxmanifest from en-US to en.
On UWP, watch that your resource name does not have a period in it..
You also likely need to tell the UWP project what its default language is. This can be done in the .csproj in the top <PropertyGroup> element (the one with no conditions) by adding <DefaultLanguage>en-US</DefaultLanguage> (using the proper culture for your scenario).
Don't forget to set the [assembly: NeutralResourcesLanguage("en-US")] as well for the assembly containing the resources - this is required for .NET Standard 2.0 and likely PCL.
Well it seems like you've got resx files for "nl" and "fr" (which you've said works fine) but you don't have one for "en". If you're trying to get the English value like that, I would think you need an "en" file the same way you do for "nl" and "fr"
I noticed that you told about NET Standard library
ResourceManager.GetString started giving null for new entries after moving from PCL to .NET Standard
I also observed that the file AppResources.Designer.cs disapeared from the Solution Explorer (but I don't know how, was still considered) and, in the VS res editon of AppResources.resx, Access Modifier was No Code Generation.
Here is what I did to fix that:
I double-clicked on AppResources.resx and set Access Modifier to Internal or Public
In .NET Standard you may no longer be able to see "View Code" from resx files; so, I righ-clicked on AppResources.resx-> Open With -> Source Code Editor and copy the new created entries to all the others *.fr (also *.nl in your case) ...
NOTE
In the context menu you should see Run Custom Tool. You may need to delete the old AppResources.Designer.cs and do "Run Custom Tool"
Don't forget to clear the solution (or olny UWP and the standard library), close VS, delete all .\bin and .\obj and restart VS. This to ensure your issue is fixed or not using the very very new generated true code :)
This is a repeat of a question asked by someone else way back in 2008
, but it appears there was no real answer back then and this is still a problem.
I am writing a Visual Studio extension for files which look like XML but are not, and do not end in an xml extension. (I am using .csp) However Visual Studio continues to parse and highlight the file as if it was XML. This makes it difficult to get my own parsing and error processing to work.
Is there any way to programmatically tell visual studio that the file is not XML?
See also similar issue on MS forum
Since you have your own file extension, yes there is! It's simply a matter of editor priority. The XML-sniffer editor is only given a chance to claim the file if nobody else with higher priority does so first. It does so by registering the special * file extension as editable, then grabbing the file if it looks like XML -- but that * extension registration only has a priority of 33.
All you need to do is make sure your editor is registered properly with a higher priority. On your package, make sure you have the ProvideEditorExtension attribute. I suggest a priority of 50 to start with (higher numbers have higher priority).
[ProvideEditorExtension(typeof(CspEditorFactory), ".csp", 50)]
If you don't already have an editor factory, there's a good walkthrough on MSDN about how to create one.
I'm in VS2010, in a new Word Add-In project. This is my first attempt at Word development using VSTO. The example I'm trying has this line:
Document vstoDoc = Globals.Factory.GetVstoObject(this.Application.ActiveDocument);
But when I add this line Visual Studio says it can't find "Factory". Indeed, it's not in Intellisense.
I've got references to:
Accessibility
Microsoft.Office.Interop.Word
Microsoft.Office.Tools.Common.v9.0
Microsoft.Office.Tools.v9.0
Microsoft.Office.Tools.Word.v9.0
Microsoft.VisualStudio.Tools.Applications.Runtime.v9.0
Office
and all the usual System references.
Where am I going wrong and why can't I get to "Factory"?
stdole
That example looks a bit weird to me. Never seen that sort of reference before.
Generally, with Vsto, you hook into EVENTS on, say, the main Word App object.
Then, from within the event, you usually are passed a reference to the particular DOC object that the event is occurring for (say, being opened or saved, etc). In that way, there shouldn't be any need for using the "globals" object or the "factory" object, whereever they might be.
What method is that code in? A little more context might help.
I think the recommended way of doing this is:
Globals.ThisAddin.Application.ActiveDocument
I've come across a strange behaviour in Visual Studio 2010.
When using embedded resources (files which are added to my C# project and for which the Build Action property is set to Embedded Resource), the files are included in the output assembly as binary data. Listing the resources is straightforward:
class Program
{
static void Main(string[] args)
{
string[] names = typeof (Program).Assembly.GetManifestResourceNames ();
foreach (var name in names)
{
System.Console.Out.WriteLine (name);
}
}
}
However, if the embedded resource file name ends with No.xxx (the extension is irrelevant), the file does not show up in the list. I cannot figure out any reason why Visual Studio 2010 would not include such a file. What did I miss?
Note: if I rename the embedded resource file in the solution explorer to something else, then everything works as expected.
Dan from the Microsoft Connect team has finally provided a valid explanation for this behaviour:
Hello, thanks for the report, this is actually working normally. The reason is that any resx files whose names match the pattern .VALIDCULTURE.resx are assumed to be specific to that culture. (This is how it has worked since VS2002, for better or worse)
In your case "no" is a valid culture (Norwegian, I guess) so the build process builds it into a satellite assembly. Here's what I got when I tried this. Note the "no" subfolder. If in your app you change your current culture to Norwegian, the resource load will load this set of resources.
So the problem has nothing to do with the word No itself, but rather with the fact that it is a valid, two-letter, culture name (in my case Norwegian). I checked, and indeed, there was a sub-folder in bin\Debug named No, containing a satellite assembly named Project.resources.dll in it.
Renaming the resource to end with .EN.xxx or .FR.xxx does, of course, exhibit the same behaviour.
As of MSBuild 16.9 you can include files like these by setting the WithCulture property to "false", as pointed out by #reduckted :-)
<EmbeddedResource Include="Resources.en.xml" WithCulture="false" />