When I try try to access a string property in one of my C# project resources, I get the following error:
'ORG.PRJ.MOD.MyClass2' does not contain a definition for 'Properties'
The code that produces the error is:
string s = MyClass2.Properties.Resources.TestString2;
The really bizarre thing is that another project in my solution (using MyClass and TestString) with exactly the same setup does NOT produce the error and works like a champ. Here is the background and all the things I have tried.
Both are plain "Class Library C#" projects in VS2008.
I created the resource strings via right-click->Properties for each project in the solution tree, then selecting the "Resources" tab. Then I just entered a "TestString" in one, and a "TestString2" in the other.
For the project that works, if I type MyClass. - the IDE IntelliSense tells me that "Properties" is an available member (but that is the ONLY member it shows me). For the project that doesn't work, the available members are "Equals" and "ReferenceEquals" (it does NOT give me "Properties"). This seems to be the biggest clue that SOMETHING is different.
Thinking my project files got corrupted, I completely created both projects again from scratch. I deleted all bin, obj, and Properties folders, deleted all Resources.resx and Resources.Designer.cs files, deleted all .csproj, .csproj.user, .sln, and .suo files. For BOTH projects. Then I started up VS2008 again and used File->New->"Project From Existing Code..." to create new projects. Then I added the resources in exactly the same way for both projects (per Step 2 above). Same results.
I have performed a 'diff' on the corresponding files between the two projects (Resources.resx, Resources.Designer.cs, MyProj.csproj). Nothing looks different other than what I would expect (class names and string names differ between them).
I've googled it to death. Based on how bizarre this feels, there's no doubt I've done something insanely stupid (see https://stackoverflow.com/questions/58640/great-programming-quotes/756768#756768).
The Properties static class is accessible via the default namespace for your project. Now, given that it's a class library, that might be Class2 (or perhaps that there might be a naming clash, ie. by having a Class2.Class2), but something tells me that that is a class in your library, not the namespace (which would produce the error you describe).
Related
We have two solutions (C#, VS2015) that consist of a few projects.
The Basic-Solution with namespace Wpf has some classes that are re-written in the More Advanced - Solution in the namespace Wpf.Advanced because the more advanced solution uses different data types for example.
Since every code-change in one of the classes, that are present in both solutions, needs to be rewritten in the second file, we decided to change the structure and use a shared project as a single place where the files should be located for both solutions.
We now use "usings" in combination with precompiler #if #else #endif blocks to merge the two files into one by changing the data types based on the project (via a compilation symbol ADVANCED).
Now to the problem:
Since some of our example projects need to reference both, the Wpf and the shared project we get the mentioned warnings CS0436 because some objects, that now exist in the shared project and in the namespace Wpf.
How can I resolve this issue?
I mean, everything works, but no warning is better than any warning, thank you!
I just had similar situation. In exe project I referenced dll and shared project. The dll in turn was referencing shared project. The solution was to exclude the shared project from the exe project. Since the shared project gets referenced from the dll the exe gets all of them too.
It may look trivial unless you are not experienced with shared projects.
The namespace NamespaceName1 in NamespaceName2 conflicts with the type TypeName1 in NamespaceName3
This error occurs when the imported type and the imported namespace have the same fully qualified name. When that duplicate name is referenced, the compiler is unable to distinguish between the two.
I'm having difficulty getting a Silverlight application working. The project is quite large, and was recently handed to me. It consists of (among other things):
A class library containing resources (let's call this MyResources). This contains a number of .resx files that contain translated strings for various labels/text in the app.
A Silverlight class library that links to all the resource files in the regular class library. (let's call this project MyResourcesSilverlight)
A Silverlight app that references MyResourcesSilverlight
From what I understand, with Silverlight you can't directly reference a regular .Net assembly because of security concerns. This makes sense, and explains the two nearly identical projects - the Silverlight class library and the regular class library. (There's a bunch of other projects that use the regular class library).
The problem I'm having is when I'm attempting to run the Silverlight app, it is failing to load any of the localized strings, and I'm getting the following error message:
Uncaught Error: Unhandled Error in Silverlight Application
Code: 4004
Category: ManagedRuntimeError
Message: System.Resources.MissingManifestResourceException: Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "MyResources.resources" was correctly embedded or linked into assembly "MyResourcesSilverlight" at compile time, or that all the satellite assemblies required are loadable and fully signed.
From the error message, it would appear that it is having difficulty pulling in the resource files - and this is also apparent from the missing text on buttons, labels, etc.
To fix this, I've tried doing the following:
Cleaning/rebuilding the solution. This had no effect.
Right clicking on the resource files and selecting "Run Custom Tool". The Custom Tool for all the resource files is set to PublicResXFileCodeGenerator. This has no effect as well, other than regenerating the code, which causes the class constructor to be internal (despite being set to public. Another problem for another day - or from what I've seen - a known issue that Microsoft is refusing to fix).
Setting all the resource files to Embedded Resource. This had no effect.
I've been looking around at other people who have had this similar issue, and have tried pretty much anything I can get my hands on, but nothing seems to work. Either I get the error message above, or I get an error message like The name 'MyResources' does not exist in the current context..
If it helps to know, the project was originally a Visual Studio 2010 project, but I've converted it to be a Visual Studio 2012 project. To the best of my knowledge, nothing has changed namespaces, which is a common cause of this problem.
Can anyone shed some light on what might be happening here? I'm quite stumped.
EDIT:
Perhaps also worth noting: I'm not seeing any sort of text on any of the forms in the Visual Studio designer. When I mouse over the supposedly missing StaticResource, it says "The resource ___ could not be resolved.". I suspect this may be an indication of a larger problem with the resource files in general. Anyone have any thoughts?
I eventually got this sorted out, but I'm still not 100% sure on what I did to fix it. This is what I did, though:
Because of the odd layout with the two library projects, whenever I would touch the MyResources project, it would automatically update the MyResourcesSilverlight project. This meant that if I did the "Run Custom Tool" on MyResources, it would regenerate the resource designer files with a namespace of MyResources. If I then went into the MyResourcesSilverlight project and did the "Run Custom Tool" on the resources there, it would then rebuild the files with the MyResourcesSilverlight namespace.
When I started digging through the XAML files that were having issues, I noticed that they were referring to things like so:
xmlns:resources="clr-namespace:MyResources.Resouce;assembly=MyResourcesSilverlight"
This made me look twice at the namespace in the files being generated inside the MyResourcesSilverlight project. Sure enough, when doing the "Run Custom Tool" on the resource files, it was generating them in the MyResourcesSilverlight namespace rather than the MyResources namespace. I set the default namespace on the MyResourcesSilverlight project to MyResources, then did the "Run Custom Tool" again to regenerate the auto-generated code. Despite manually setting the auto-generated code to create things as public, I still had to manually go in and switch the class constructor from internal to public. Once I did that, things seemed to start working.
So if I were to sum this up, I'd say look at the following:
Verify the namespace that your XAML files are using and the namespace of the auto-generated code in the resource files. They should match.
Verify that the constructor of the auto-generated code is public. Don't trust the Custom Tool.
Hopefully this helps out anyone else who might be stuck on a similar issue.
In a Visual Studio 2010 project, we had two identically named classes in two different namespaces that are both commonly included in ViewModels throughout the application. One such class has since been deprecated and removed, but I'm getting an ambiguous reference error when directly referring to the remaining class, even though the old class no longer exists.
We basically have something like this:
using OurNamespace.UI.Common;
using OurNamespace.SomewhereElse;
// *snip*
SomeClass.SomeMethod();
Once upon a time, both of the above namespaces had a SomeClass, but we deleted the one in OurNamespace.UI.Common. However, when building, we get the following error:
'SomeClass' is an ambiguous reference between 'OurNamespace.UI.Common.SomeClass' and 'OurNameSpace.SomewhereElse.SomeClass'
I've already tried cleaning the solution and rebuilding as suggested in answers to this ambigous reference question, only to continue to see the error. What's still lurking behind that makes it think the deleted class still exists for purposes of an ambiguous reference? Even IntelliSense knows there's only one now.
If you look at your project's references (via the References section of the Solution Explorer window), you can right-click the reference and select View in Object Browser.
This allows you to investigate the referenced assemblies to see if the offending class is still lurking in any of them.
There's still a reference to the namespace that the old class used to be in (because it has other things in use)
I think your problem is with the reference to the dll that used to contain the deleted class.
Simply remove the reference and re-add it. It should solve the issue.
Super old thread, but in VS2017 I had this happen and had to restart VS to get it fixed after I moved files between namespaces.
I have a C# project with two namespaces. A GUI (Stoff3GUI as namespace) with the GUI xaml and .cs files, marked as starting object and a Library (Stoff3Lib as namespace) with all the classes doing the actual work.
Now, when I compile my code, I will receive a .exe file Stoff3GUI.exe and a .dll Stoff3Lib.dll. In Visual Studio, both namespaces are part of the same Project.
How can I compile the classes from the Stoff3Lib into the .exe file without producing a separated .dll file?
Edit:
Changed the xxx to my project name Stoff3 for better understanding.
If both namespaces are part of the same project, you should already only end up getting a single assembly.
This can differ with web project setups (various different flavours of web projects create assemblies in times and manners I've never understood) but for standalone executable projects, it really is "one project produces one assembly" in all cases as far as I'm aware. Double-check that you really only have one project - for example, you shouldn't have any references in the project to an xxxLib assembly.
I'm not entirely sure what you are doing here. It sounds like you might have a single 'Solution' with two projects My immediate thought is just to move the classes you want into the the GUI start project and delete the other project.
I believe what you really have is 1 Visual Studio solution with 2 projects.
Since a picture is worth 1000 words, and just to clear up terminology, here's what that looks like in VS2012:
The output of this solution is exactly what you describe:
TwoProjects\Stoff3GUI\bin\Debug\Stoff3GUI.exe
TwoProjects\Stoff3Lib\bin\Debug\Stoff3Lib.dll
The easiest way to accomplish what you want is to have a single VS project that contains 2 different namespaces. It's good practice to add folders that match your intended namespace structure, in your case Stoff3GUI and Stoff3Lib:
When you compile this solution, the output will be a single EXE, but you still maintain the separation of model and view namespaces very clearly in your folder/file structure:
OneProject\bin\Debug\OneProject.exe
Projects are often broken down into folders, and those folders are typically expected to map to code namespaces. However, in many of my core projects I have classes that I have merged into existing namespaces - for example I have an MVC reference library that adds additional types into System.Web.Mvc, or System.ComponentModel.DataAnnotations, for example.
In other projects, I might have a suite of interfaces and a suite of default implementations of those interfaces; so I might split the code files into two separate folders (e.g. 'Objects' and 'Interfaces') but I don't want to have Objects and Interfaces sub namespaces.
Equally, I often write extension methods for types in other libraries - e.g. System.String, which I merge into the System namespace so they are already 'there' as soon as you reference the assembly.
So given a project structure like this (in response to the first answer, this project is intended to produce a single assembly with all the namespaces; and could be a dll that might be signed):
Our.Core.Library
|->System
| |->StringExtensions.cs
|->System.Web.Mvc
| |->AnotherModelBinder.cs
|->OurCoreClass.cs
In the above, I want new files added to the root to be in the namespace Our.Core.Library, but I want new files added to the System and System.Web.Mvc folders to be in System and System.Web.Mvc respectively. But VS will give them a default namespace of Our.Core.Library.System.
It's a small gripe, but I'd like to be able to override the default namespace for a specific code folder so I can control it. Any ideas how to achieve this? I've tried an empty default namespace for the project, which might logically make it work for sub-folders, but obviously not for the root; however, the VS Properties page doesn't accept an empty namespace.
Ideally it would be a solution that I can easily replicate across our entire dev team to enable other developers to be able to add code files whilst adhering to the namespace structure set out at the architect/planning stage.
Every C# project settings has a Default namespace option in the application tab that you can change to any other value which will take effect when you add more files to the project. There is only one setting allowed per project
You can break your project into multiple projects and have the default be different for different projects
Basically the only way I'm going to be able to do this is to write my own extension to Visual Studio. It might even require it's own project or item wizard - if I can get anything working I'll post it up here in the future.