Object Browser, Fully Qualified Assembly Name, and Config Files - visual-studio-2010

I needed to add a System class to my config file, and found it would not work unless given a fully qualified assembly name. Ok, no worries, I'll simply look that up.
Uh oh.
I expected the Object Browser in Visual Studio to have that information. That would be too obvious. It was not there. I started to search for how to get this information, and found MSDN for .net 4 telling me to use Mscorcfg.msc, except MSDN also says that Mscorcfg.msc "has been removed from .NET 4 and later versions." This is not an auspicious beginning.
Of course there are answers that explain how to do it programmatically; I already know how to do that, and that isn't the point. I don't want to write my own program just to find the publickeytoken of an assembly I want to put into my config file.
I then find an article suggesting "sn.exe" for files not in the GAC, and an answer suggesting the gacutil for everything else. A few others suggest using RedGate's Reflector. Sigh.
I'm trying to figure out why such a common activity - inserting a fully qualified assembly name into a config file - requires such a "Visual Studio 6 era" hokey-pokey firedrill to get such a simple thing done. So we come full circle: Why on EARTH does the object browser not simply provide this information? Please tell me there is a simple VS configuration option I've missed, that explains how this is done.
To be clear, yes, I have obtained the FQAN I was seeking. I just don't think resorting to GACUTIL.exe, after googling for a while in disbelief, should be the right answer. What am I missing?

Related

How to Get Some Basic Info from a DLL File?

Assume you have a .DLL file, and you want to know some basic information regarding it,
for example:
Is it a Managed (.NET) or Non-Managed (e.g. COM, etc) DLL
If it's Managed, what minimal version of .NET it requires
(and if it's non-managed, then any other minimal version that it requires? for example minimal version of Windows, or of something else)
Any other kind of such metadata
Please note that I am less interested in seeing the Function Headers (or Classes) that are inside.
Visual Studio's Object Browser can show the Functions/Classes very well,
yet I did not find a way to make Object Browser show the metadata that I mentioned above..
So maybe another utility can do it?

VS2010 to VS2012 ToolWindow XAML Reference VsBrushes

So I thought I'd run this out there, and see if I was missing something idiotic.
I developed a small my-use-only VSIX extension, and in one of my toolwindows, I'm using the code to set the foreground/background color:
Foreground="{DynamicResource {x:Static vsfx:VsBrushes.ToolWindowTextKey}}"
Background="{DynamicResource {x:Static vsfx:VsBrushes.ToolboxBackgroundKey}}"
The vsfx: namespace is referenced as:
xmlns:vsfx="clr-namespace:Microsoft.VisualStudio.Shell;assembly=Microsoft.VisualStudio.Shell.10.0"
I see the 10.0 referenced there, and for me, that's expected as I originally did this up in VS2010. Now that my work has made me upgrade to VS2012, the XAML designer is giving me the following error on those two SynamicResources. The error reads 'The resource {x:Static vsfx:VsBrushes.ToolWindowTextKey} could not be resolved.' and like for the second one.
Now, note that the project still builds and runs, and can be loaded into VS2012. However, the colors are all off (standard, don't match the theme that VS is set to.)
Any thoughts on what to check or look for?
Cheers -
Mike.
I ran into the same question as you guys do, and found out the follow facts:
[VsBrushes/VsBrush] v.s. [EnviromentColors]:
VsBrushes and VsBrush are basically the same thing, supported in VS2010/2012/2013;
EnviornmentColors is only in VS2012/2013, not supported in VS2010;
EnvironmentColors is still envolving, more colors will be added in for new themes; VsBrushes/VsBrush are relatively static.
[VsBrushes] v.s. [VsBrush]:
Good thing about “VsBrushes” is that it checks whether a specific color name exists during building.
Bad thing about “VsBrushes” is that is has to specify the VS namespace and assembly version in the XAML file head, which is inconvenient. (e.g. xmlns:vsfx="clr-namespace:Microsoft.VisualStudio.Shell;assembly=Microsoft.VisualStudio.Shell.10.0")
Thanks.
Use EnvironmentColors class as it's stated here:
http://msdn.microsoft.com/en-us/library/vstudio/jj991932.aspx

vb6 user-defined type not defined error on full compile

I have some vb6 code I have not compiled in a long time. The last compile is in production. Now I get an error "User-defined type is not defined" when I do a full compile. I'm sure there is a reference missing. But there is no code that is hi-lighted. And I cannot seem to find what reference might be lost.
Any clues as to what I can do to find the missing reference would be very helpful.
Thanks!
Dave
I've had that happen before it drove me crazy!! But then I found this:
 
http://support.microsoft.com/kb/190197
 
Occurs when compiling with binary compatibility on. The above solution suggests turning off binary compatibility and re-compiling - then missing reference will then be highlighted.
Other steps you can try:
Rather than turning off BC for everything look for ones that have
been recently changed
search C: drive and dev folder and delete any
*.oca files
also look in the vbp file for any oca references
You need to ensure that you have the appropriate items checked in the References dialog. This is outside the code and they are listed in the VBP file (text file).
EDIT Corrected reference storage. Thanks MarkJ
Make sure all of your object types are spelled right. A simple error like spelling Variant Varient can cause this error as well.
Are you still using the same machine in which the original compile was made and / or with the same OS
?
If the answer is no, then there is a chance that VB6 or its like linked to a reference which is no longer available in Win7 or later, this may also include the compiler if you are using a modern version of studio.
Since the code is also in VB6, if you are using any outside commercial controls, and again if not on the same machine, you would loose those links as well if you did not port over the library.

Lots of type errors in Visual Studio Error List -- until I build and then they are gone

I recently added a new project to my Visual Studio 2008 solution. Now, as I make edits in the new project, I receive a ton (~50) of type checking errors - indicating that an assembly reference may be missing. However, when I actually build the solution, the errors go away. As best I can tell, my dependencies are set and the build order is correct. What could be wrong?
It doesn't prevent me from building and deploying, but it's a major nuisance. It makes it hard to tell when I actually have introduced new errors (until I do compile). Thus, it erodes the usefulness of having the error window do static analysis.
Example, one of the 50 errors is this:
"The type of namespace name 'PersonManager' does not exist in the namespace 'Gideon' (are you missing an assembly reference?"
In reference to this line of code:
Gideon.PersonManager pm = new Gideon.PersonManager()
PersonManager is underlined in both places, and when I right click the type and selected 'find all references' I get an alert box that says "Cannot navigate to PersonManager"
However, the references are definitely there, because when I build, it works.
One other detail is that there is a mixture of C# and VB.net code, though I don't think that should make a difference.
Well, yes, the IntelliSense parser is not an exact replica of the C# compiler. It has a very different job to do, it needs to do something meaningful while the code is utterly broken since you are editing it. Tough assignment, they did a tremendous job with it. But as a side-effect, it can fail to parse things that are actually legal. It's quite rare but not unheard of, seen it myself a few times.
This won't go anywhere concrete until you at least give us some idea of what kind of errors you are seeing, along with a snippet of the code that generates them. You didn't do so, I can only recommend that you select another window so you don't have to look at them.
I had the same problem. I had a project in my solution that was causing the problem - I removed the project from the solution, then added a reference to that project in the main solution and the errors went away. Strange that it only happened on 1 machine. Opening the solution on another machine was fine...

How do I see the contents of Qt objects during debugging?

Many Qt classes uses pimpl, so they're very opaque to VS's debugger.
This is bothersome when I want to check some internal Qt state to see if my code is doing it wrong or if I'm having wrong expectations of how things stand.
I'm using the Qt VS add-in (1.1.0), but that doesn't seem to help.
Any ideas?
Update
My autoexp.dat file is filled with Qt stuff, but I'm still not able to look inside the heavier classes (QWidget, QTcpSocket, etc).
I can see the simpler classes contents, so the autoexp.dat below seems to be working, but trying to look inside a QWidget doesn't work.
Update 2
For some reason, after reading comments and looking more, it does work, and I can see the data stuff.
I don't know what happened in the mean time (when I just worked and ignored it), but I did have problems seeing the data before.
I'm accepting the "just works" answer, because I can't delete a bountied question and that's the closest answer available. (The autoexp-dat just pretty-formats the debug lines, using data that's already visible if one digs down)
This might help http://daniel-albuschat.blogspot.com/2008/02/qt-debugging-with-visual-studio-2005.html
IIRC the install of Qt for Windows includes an autoexp.dat file -
Correction, it's part of the the qt-vs-addin
You need to add custom dumpers for your debugger.
There are pre-built ones for GDB. You may have to roll your own for other debuggers, although for visual studio it's possible to get some decent results pretty easily by tweaking the autoexp.dat file. There are plenty of resources online for how to change this file.
Editing autoexp.dat is an option. See http://eecs.vanderbilt.edu/research/hmtl/wiki/pmwiki.php?n=Knowledge.Qt for a set of visualizers.
It seems like you might be out of luck.
Currently this page has the most complete list of macros for QT wariables that can be added to the autoexp.dat:
QT with Visual Studio 2008 (updated for Qt 4.5.2)
ActiveQt also sounds promising, but it might be a bit of an overkill for you.
Beyond this, you would have to roll your own expressions, or maybe write a Visual Studio Debugger Visualizer. (more about that is on CodeProject or MSDN)
Since there is nothing like that out there, it might be a good opportunity for development from scratch. :)
It's definitely possible to look into the pimpl when Qt is compiled with debugging information. Not sure about VS, but with gdb it Just Works™.

Resources