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
Related
I'm pretty sure this is a bug in the VB6 IDE but I haven't found any definitive reference to it before...
Sometimes when I've loaded a project which has some dependency issue (missing reference, etc.) the IDE will show an error like this:
("Compile error: Can't find project or library")
Note the text which it highlighted is a call to the UCase$ function which is essentially built into the language. There's no way its library is actually missing.
Is this a known bug? Is there any rhyme or reason to the text which is selected when this happens?
Update: The standard libraries which include things like UCase() are included so that is not the actual problem. The highlight really seems to be nonsensical.
VB can do some strange things, but... check both the content and order of your References. UCase$() isn't 'built into the language' in the way you might think -- it's not in the VB runtime, but in the VBA runtime, which must be included as a reference.
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?
I experience a strange behaviour in Visual Studio 2010 when creating Windows Phone 7 apps. After some time VS starts to complain about Invalid XAML although there is no problem and the app compiles and runs just fine.
It bugges me because I cannot use the visual desingner saying "Exception was thrown on "DataTemplate": Invalid XML" and there is a DataTemplate higlighted in the code. The data template is always ok, VS does not complain about it when copy-pasted to another project.
I found out that problematic are usually the DataTemplates with custom converters or when usin g classes like PhonePerformance.
Sometimes the error is "Exception thrown was due to document error: Invalid XML" and nothing is even highlighted in the XAML file.
I tried reinstalling .NET. Visual Studio etc. and the problem occurs on two separated machines so I do not think it is specific to my configuration. It may be specific to my code.
Anyone experienced similar behaviour?
When using XAML, if you reference a library that needs to be evaluated but can't be at design time you get this kind of error. You can turn off the visual editor and just work in XAML - that will stop the error (and save you time).
You reinstalled .NET and VisualStudio??? You should have just spun up a second instance, opened the solution in both, then attached the debugger from one to the second and opened up the visual editor. It would have told you exactly what in your code was causing the problem. Also DesignerProperties.IsInDesignMode in your converters. Jeez. You wasted so much time :(
As for design time data, that's tricky. Either you have DesignTimeDataWithDesignTimeCreatableTypes that aren't or DesignData that can't create proxies for your real types (for whatever reason, had this issue many times deep in the past).
The only way to figure this out is to debug one instance from another. Its actually not that hard. I do it alot (debugging WF4 ActivityDesigners).
A friend has found a solution and you would not believe where the problem is. This happens if you have a space in the name of your assembly. I found out that I really have a space in assembly name in all the problematic projects, renamed the assemblies and the designer works again.
The solution is also mentioned here http://forums.silverlight.net/t/115011.aspx/1
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...
I have a little problem with the creation of a user control.
Though I have made a control I want to use in another control.
As soon as I want to add the reference (would like to use it as compiled OCX) in the Component's list, the message "Wechselseitiger Verweis zwischen Projekten nicht zulässig" which means something like "Circular referencing between projects is not allowed"
Strange is that the control I want to use does not have any type of reference to the first project.
I've checked this using dependency walker which is shipped as a tool with Visual Studio, but it says as well that there's no reference to the other control. I've opened the project-files using a text-editor to check for referenced OCX, I didn't find any.
To avoid some comments: change to .NET or any other language is not an option.
Comment: Why ever, adding the uncompiled .ctl-file seems to work. For now I can continue my work. But anyways I'm interested in a solution and the reason why it doesn't work with the current constellation.
VOTE FOR CLOSE: I've been looking at all the files, well and now I've just simply added all control-files to the project instead of creating OCX. I'll give it up. Thanks to all...
It is possible for VB6 to get quite confused when you add references to OCX files. You should really be adding an OCX as a component instead of using Project References.