Expression Blend: Getting error "XXX" does not exist in the namespace "XXX", but not in VS2008 - expression-blend

I am trying to use Blend 3.0 to edit a project that contains some WPF controls. This project already compiles and runs fine from Visual Studio 2008.
In Blend however, I'm getting mysterious errors that make no sense:
For example, I have a class that derives from Control :
namespace Company.WPFControls.SearchTextBox
{
public class SearchTextBox : Control
{
...
}
}
And I try to use it in a resource, in the same assembly, to assign a style:
<ResourceDictionary
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:local="clr-namespace:Company.WPFControls.SearchTextBox"
<Style TargetType="{x:Type local:SearchTextBox}">
...
</Style>
</ResourceDictionary>
I get the following error in Blend:
The name "SearchTextBox" does not
exist in the namespace
"clr-namespace:Company.WPFControls.SearchTextBox".
I've tried specifying the assembly name, by adding ;assembly=Company.WPFControls but it doesn't remove the error.
Is there any way to fix this or at least figure out where the problem comes from?

I had the same problem with Blend 2, on a Windows Vista 64.
I normally compile my solution in VS2008, with a "Debug - x86" target on all my projects, so that it's compatible with some other 32 bits-only projects.
It looks like Blend loves the "Debug - Any CPU" targets.
I basically changed my configuration manager so that it targets Any CPU platforms instead of x86.
So...
Open your solution in Blend and in VS2008
In VS2008, choose the menu Build ->
Configuration Manager
Ensure that your solution
configuration has a "Debug - Any CPU"
for all projects
Compile in VS2008
tadaaaa Your blend project should update and remove those errors...
well it did for me
I did the opposite to verify if it was really that, and it seems yes... I simply reverted the solution changes back to Debug - x86, cleaned everything, and rebuilded, and I was still back with the error "Does not exist [...]"
As for the "Why?"... I don't know, but at least it works now!

The problem is in Blend assembly search path. By default it search classes in assemblies in folder "bin\Debug"! But if you set in project configuration target x86 then your output path will be "bin\x86\Debug". So you need to change your output path in visual studio to "bin\Debug" and Blend will find all your classes!

I think that Blend uses the default config/platform defined in the project file. You should be able to fix this by editing it with a text file. If you look in your .csproj file, you should see something like this:
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
...
Change that AnyCPU to x86 and it should work the way you expect.

You can also fix this "Any CPU/x86" issue by changing the output path for all your projects to bin\Debug instead of bin\x86\Debug (same for Release).

I also had an error like this. But for me it helped to rebuild the project directly in Blend without using Visual Studio.
For those who don't know: You can do this in Blend in the Menu by clicking on "Project" -> "Rebuild Project".
At least in Blend 4.

Related

Is it possible for a C++ (vcxproj) project to reference a net5.0 C# project

I have a C# class library project which I consume from a C++ project. This works perfectly well when:
the C# project has TargetFramework set to netstandard2.0
the C++ project has TargetFrameworkVersion set to v4.7.2
However, I now need to upgrade the C# library to net5.0...
the C# project has TargetFramework set to net5.0 (using new style project file)
the C++ project has TargetFrameworkVersion set to v5.0
and receive this error....
C:\Program Files\Microsoft Visual
Studio\2022\Preview\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(1806,5):
error : Project '..\cslib\cslib.csproj' targets 'net5.0'.
It cannot
be referenced by a project that targets '.NETFramework,Version=v5.0'.
Note that it's not possible to set the TargetFrameworkVersion for the C++ project to "net5.0" or "net5.0-windows" since that results in a project load error:
It's not clear that "v5.0" is the correct TFM for a C++/vcxproj format file - it's possible msbuild is just falling back to v4.7.2 by default but I can't think of a better alternative.
Is there a way to accomplish this? It seems like it should be possible to target net5.0 in a C++ project by now. (I'm using Visual Studio 2022 Preview and PlatformToolset is set to v143 which is the latest).
It's a bit tricky, but the following should help:
If using the GUI, the following settings need to be made in properties: Under "Root->Extended" setting "Common language runtime support": "Net Core runtime support /clr:core" and ".NET Core Target framework": ".NET 5.0" (you might need to click "apply" after choosing the first, to get the possible settings in the second box to update)
In the .vxcproj, this results in:
...
<PropertyGroup Label="Globals">
<TargetFrameworkVersion>v5.0</TargetFrameworkVersion>
<Keyword>ManagedCProj</Keyword>
<TargetFramework>net5.0</TargetFramework>
...
</PropertyGroup>
and (once for each build configuration):
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="Configuration">
<ConfigurationType>DynamicLibrary</ConfigurationType>
<CharacterSet>Unicode</CharacterSet>
<PlatformToolset>v142</PlatformToolset>
<CLRSupport>NetCore</CLRSupport>
...
</PropertyGroup>
Note that it is not possible to create C++ exes in .NET Core. C++/CLI projects must be libraries and cannot contain the main entry point (create a stub-loader C# project if you have to).
You may then experience:
error NETSDK1145: The Apphost pack is not installed
This documentation suggests this can be overcome by modifying the project file but if that does not work, a global.json file can be added in the solution root folder to point to the desired SDK.

Visual Studio 2013 and Qt5: QTDIR set too late

Everything works with Qt in MSVC2013, except one thing: the DLLs are not found, because $(QTDIR) is not defined, when the local debugging environment is set.
My debugging environment settings:
PATH=$(QTDIR)\bin%3b$(PATH)
My .user file:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
<LocalDebuggerEnvironment>PATH=$(QTDIR)\bin%3b$(PATH)</LocalDebuggerEnvironment>
<QTDIR>C:\Qt\Qt5.4.1\5.4\msvc2013</QTDIR>
<DebuggerFlavor>WindowsLocalDebugger</DebuggerFlavor>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
<LocalDebuggerEnvironment>PATH="$(QTDIR)\bin%3b$(PATH)</LocalDebuggerEnvironment>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
<LocalDebuggerEnvironment>PATH=$(QTDIR)\bin%3b"$(QTDIR)\bin%3b$(PATH)</LocalDebuggerEnvironment>
<QTDIR>C:\Qt\Qt5.4.1\5.4\msvc2013</QTDIR>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
<LocalDebuggerEnvironment>PATH="$(QTDIR)\bin%3b$(PATH)</LocalDebuggerEnvironment>
</PropertyGroup>
</Project>
I don't know why, but the $(QTDIR) variable is not available to LocalDebuggerEnvironment.
It works with following debugging environment settings:
PATH=C:\Qt\Qt5.4.1\5.4\msvc2013\bin%3b$(PATH)
Is it possible to make Visual Studio handle this properly or do I have to enter the path manually?
It seems Visual Studio parses the lines from top to bottom, so with your code...
<LocalDebuggerEnvironment>PATH=$(QTDIR)\bin%3b$(PATH)</LocalDebuggerEnvironment>
<QTDIR>C:\Qt\Qt5.4.1\5.4\msvc2013</QTDIR>
...the variable $(QTDIR) is defined in the second line, and is cannot be used in the first line.
Simply switch the order so that the variable is defined before it is used:
<QTDIR>C:\Qt\Qt5.4.1\5.4\msvc2013</QTDIR>
<LocalDebuggerEnvironment>PATH=$(QTDIR)\bin%3b$(PATH)</LocalDebuggerEnvironment>
Note: Visual Studio only reads the .user file at startup, so you need to (re-)start Visual Studio after editing the file.
Thank you for your discussion of this issue. I can report that it still is extant in Qt 5.8 / QT Extension for Windows Version 2.1.1 / Visual Studio 2015. The symptoms are that entering "$(QTDIR)\bin" (the location of the Qt DLLs) as a PATH folder spec in the VStudio Project property Debugger...Environment appears to work, but actually does not.
By "appears to work" I mean that if you click on the option to examine the Debugger Environment property, and the raw form of the Environment property looks like "PATH=$(QTDIR)\bin;...;$(PATH)" the VStudio editing dialog box will helpfully inform you that that PATH string evaluates to (e.g.) "PATH=D:\TechApps\Qt\5.8\msvc2015_64b\bin;..."--just as it should if the QTDIR macro was really present and had the correct value. This is cruelly deceptive!
Because, by "really doesn't work" I mean that the PATH as actually prepared for use when launching your Qt-dependent application from within VStudio doesn't see this macro. Your beautiful PATH string is reduced to "\bin;...". You can confirm this by temporarily copying your Qt DLLs from $(QTDIR)\bin into the folder of your application executable. Your application will launch correctly. And if you examine your PATH from within your program (using e.g. getenv("PATH") in c++, you will see that your program's PATH string is missing QTDIR. (That is, it is what it would be if QTDIR were the empty string.)
FWIW, another symptom of this problem is that if you examine the VStudio list of macros, $(QTDIR) is not in the list.
The solution described above (rearranging the elements in ...vcxproj.user) appears to solve the problem. When you move the definition(s) of QTDIR earlier in that file, the PATH string actually available to the application is correct, and $(QTDIR) is present in the list of macros known to Visual Studio.
HOWEVER, I don't know whether changing the "Qt VS Tools" options, or the "Qt Project Settings," in VStudio causes the .user file to be incorrectly overwritten again.
Changing (or re-selecting) the Qt Version in the solution (Change Solutions Qt Version) fixed the issue for me.
It took many seconds to re-initialize the projects and even then I don't believe the .user file updated until I did a build of the project.

Build Customization for CUDA 5.0 not found in Visual C++

I am trying my hand at CUDA gpu programming for the first time and have come across a problem when setting the build customization. I'm not sure if I'm just doing something wrong or not. Basically, when I set the projects build customization to CUDA 5.0, it doesn't work. I try to make a .cu (and even .cpp) file and I get an error stating:
The imported project "C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V110\BuildCustomization\CUDA
5.0.props"was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
c:\Users\"USER NAME"\documents\visual studio 2010\Projects\"PROJECT
NAME"\"PROJECT NAME".vcxproj
Afterwards the project property page becomes empty with only a Frameworks and References page which is empty. Turning off the CUDA declaration does nothing.
I have tried uninstalling the CUDA toolkit and reinstalling it but to no avail.
I'm pretty new at this, but any help would be appreciated!
In order to use CUDA build customization, some files should be copied to Visual Studio folders, in your case CUDA 5.0.props is missing from
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\BuildCustomization\
In order to fix this, search for CUDA 5.0.props in your C: drive and copy it to the above path.
This happened to me just now and the solution I did was re-run the CUDA installer and make sure to select Visual Studio integration.
This can also happen if you don't have CUDA installed on the machine. This could be quite common for instance you might be using your laptop to develop the project and it has no CUDA card. Anyway to fix this you need to edit the Visual Studio project file .vcxproj (anyone from NVIDIA listening?)
change
<Import Project="$(VCTargetsPath)\BuildCustomizations\CUDA 8.0.props" />**
to
<Import Project="$(VCTargetsPath)\BuildCustomizations\CUDA 8.0.props" Condition="exists('$(VCTargetsPath)\BuildCustomizations\CUDA 8.0.props')" />
and then
<Import Project="$(VCTargetsPath)\BuildCustomizations\CUDA 8.0.targets" />
to
<Import Project="$(VCTargetsPath)\BuildCustomizations\CUDA 8.0.targets" Condition="exists('$(VCTargetsPath)\BuildCustomizations\CUDA 8.0.targets')" />
Then right click on the project icon in visual studio and select the reload option, the project should reload, even if you haven't got CUDA installed on that particular machine.
You might have to do some further steps, eg. use #ifdef
to exclude these include files and other cuda code sections.

Setting executable icon in Visual C++ 2010 Express

I'm rather unfamiliar with programming tools in Windows but have been forced to use VC++ 2010 Express for a project recently. We have been working on a piece of software that we didn't start and now we are reaching the finish line. Only problem is that I want to be able to set the executable icon.
Since the project is written mostly in SDL we have set the titlebar icon using the SDL_WM_SetIcon call as recommende on several sites but I still can't find any references to how to set the executable icon. All my google searches has turned up results about Visual Studio 2010 and Visual C++ 2008, neither of which seems appicable.
Since VC++ 2010 Express lacks resource editor but not resource compiler this can be done by manually creating a resource.rc file in the project directory (same as where your .vcxproj files are located), also drop in your .ico version of your icon in the same directory.
In resource.rc add the following line:
IDI_APP ICON "icon.ico"
And add the file, in VC++, to the Resource Files.
Doing this in VC++ should result in something like this to be added to your .vcxproj:
<ItemGroup>
<ResourceCompile Include="resource.rc" />
</ItemGroup>
And to your vcxproj.filters:
<ItemGroup>
<ResourceCompile Include="resource.rc">
<Filter>Resource Files</Filter>
</ResourceCompile>
</ItemGroup>
I ran into a similar situation recently with the Express edition.
I came up with a different way to approach this (see gif).
Posting it here in case someone runs into similar problem.

How do include paths work in Visual Studio?

Visual Studio drives me crazy and I am suspecting I am doing something wrong.
This is what I do: I installed Visual Studio (Pro '08) a long time ago, I installed the Windows SDK (Win 7 x64), someone emails me a project, it fails to build.
Invariably, it can not find windows.h. While it is easy enough to include C:\Program Files\Microsoft SDKs\Windows\v7.0\Include in the project settings of every single project, I feel that this may not be the proper way to do it. Is there a way to somehow make Visual Studio globally aware of these files?
I also tried to include the above directory in the path variable but that didn't change anything.
Also, it will randomly find windows.h but not winresrc.h in the same directory.
Edit:
It was a problem with my machine. Somehow, Visual Studio thought that my Windows SDK was in the wrong place. See accepted answer and comments for the fix.
#RichieHindle solution is now deprecated as of Visual Studio 2012. As the VS studio prompt now states:
VC++ Directories are now available as a user property sheet that is added by default to all projects.
To set an include path you now must right-click a project and go to:
Properties/VC++ Directories/General/Include Directories
Screenshot:
This answer only applies to ancient versions of Visual Studio - see the more recent answers for modern versions.
You can set Visual Studio's global include path here:
Tools / Options / Projects and Solutions / VC++ Directories / Include files
To resume the working solutions in VisualStudio 2013 and 2015 too:
Add an include-path to the current project only
In Solution Explorer (a palette-window of the VisualStudio-mainwindow), open the shortcut menu for the project and choose Properties, and then in the left pane of the Property Pages dialog box, expand Configuration Properties and select VC++ Directories.
Additional include- or lib-paths are specifyable there.
Its the what Stackunderflow and user1741137 say in the answers above.
Its the what Microsoft explains in MSDN too.
Add an include-path to every new project automatically
Its the question, what Jay Elston is asking in a comment above and what is a very obvious and burning question in my eyes, what seems to be nonanswered here yet.
There exist regular ways to do it in VisualStudio (see CurlyBrace.com), what in my experience are not working properly. In the sense, that it works only once, and thereafter, it is no more expandable and nomore removable.
The approach of Steve Wilkinson in another close related thread of StackOverflow, editing the Microsoft-Factory-XML-file in the ‘program files’ - directory is probably a risky hack, as it isnt expected by Microsoft to meet there something foreign. The effect is potentally unpredictable. Well, I like rather to judge it risky not much, but anyway the best way to make VisualStudio work incomprehensible at least for someone else.
The what is working fine compared to, is the editing the corresponding User-XML-file:
C:\Users\UserName\AppData\Local\Microsoft\MSBuild\v4.0\Microsoft.Cpp.Win32.user.props
or/and
C:\Users\UserName\AppData\Local\Microsoft\MSBuild\v4.0\Microsoft.Cpp.x64.user.props
For example:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ImportGroup Label="PropertySheets">
</ImportGroup>
<PropertyGroup Label="UserMacros" />
<PropertyGroup>
<IncludePath>C:\any-name\include;$(IncludePath)</IncludePath>
<LibraryPath>C:\any-name\lib;$(LibraryPath)</LibraryPath>
</PropertyGroup>
<ItemDefinitionGroup />
<ItemGroup />
</Project>
Where the directory ‘C:\any-name\include’ will get prepended to the present include-path and the directory ‘C:\any-name\lib’ to the library-path. Here, we can edit it ago in an extending and removing sense and remove it all, removing thewhole content of the tag .
Its the what makes VisualStudio itself, doing it in the regular way what CurlyBrace describes. As said, it isnt editable in the CurlyBrace-way thereafter nomore, but in the XML-editing-way it is.
For more insight, see Brian Tyler#MSDN-Blog 2009, what is admittedly not very fresh, but always the what Microsoft is linking to.
If you are only trying to change the include paths for a project and not for all solutions
then in Visual Studio 2008 do this:
Right-click on the name of the project in the Solution Navigator. From the popup menu select Properties. In the property pages dialog select Configuration Properties->C/C++/General. Click in the text box next to the "Additional Include Files" label and browse for the appropriate directory. Select OK.
What annoys me is that some of the answers to the original question asked do not apply to the version of Visual Studio that was mentioned.
To use Windows SDK successfully you need not only make include files available to your projects but also library files and executables (tools).
To set all these directories you should use WinSDK Configuration Tool.
This answer will be useful for those who use a non-standard IDE (i.e. Qt Creator).
There are at least two non-intrusive ways to pass additional include paths to Visual Studio's cl.exe via environment variables:
Set INCLUDE environment variable to ;-separated list of all include paths. It overrides all includes, inclusive standard library ones. Not recommended.
Set CL environment variable to the following value: /I C:\Lib\VulkanMemoryAllocator\src /I C:\Lib\gli /I C:\Lib\gli\external, where each argument of /I key is additional include path.
I successfully use the last one.
You need to make sure and have the following:
#include <windows.h>
and not this:
#include "windows.h"
If that's not the problem, then check RichieHindle's response.

Resources