I am not entirely sure how to better word this question, as I am not entirely sure what the central cause is to these various reference problems, so I apologize in advance for the vague title.
I am writing apps in VS 2012 Express for Windows 8, targeting a winRT (ARM) surface tablet.
I am having multiple problems with references apparently being recognized in their entirety. For simplicity, let me illuminate with some examples.
I am writing some code involving SOAP xml.
First, if I reference "System.Xml" (as well as System.Xml.Linq) by explicitly including a "using.." line, it doesn't seem to actually do anything.
using System.Xml.Linq;
using System.Xml;
...
XmlDocument xmldoc = new XmlDocument();
throws "The type or namespace name 'XmlDocument' could not be found"
Likewise if I am more explicit:
using System.Xml.Linq;
using System.Xml;
....
System.Xml.XmlDocument xmldoc = new System.Xml.XmlDocument();
throws "The type or namespace name 'XmlDocument' does not exist in the namespace 'System.Xml'" as well as the original error message.
Ok. I'm clearly missing something, but there's tons of google results for things like this.
I am running VS2012 on Windows 8 installed on VirtualBox, and thinking perhaps my installation was hosed, I first tried simply reinstalling VS2012, then repairing the installation when this did not seem to affect anything.
Next, I tried manually adding the reference to the .dll files in question. When I tried this, VS would not allow it, saying they are already included by default.
Next, I tried manually opening the .csproj file for my project, and adding Reference Include = "... lines for a few references which I seemed to be missing (like I said, I'm just using System.Xml as an example.) This didn't appear to change anything, as I was getting exactly the same errors.
Next, I went into "Add or Remove Programs" on a google-inspired hunch and, through Control Panel -> Add/Remove Programs, I turned on .Net Framework 4.5 Advanced Services. This unfortunately did not seem to have any effect.
Adding various .dll-containing paths to "Reference Paths" also did not seem to affect anything at all (that field was empty upon first installing VS.)
I am stumped. Am I missing .dlls or other files, even after repeated re-installation and repairs?
Note that I was able to at least create an XmlDocument by referencing Windows.Data.Xml, Windows.Data.Xml.Dom but that namespace seems to be lacking some methods I need.
System.Xml.XmlDocument is not available for Windows Store applications. Take a look at the MSDN page - classes, methods, and properties marked with the green shopping bag are the only ones you can use with Windows Store apps.
As for System and Windows namespace references, all of the ones you can use are already part of the .NET for Windows Store apps Reference in your project, so there's nothing that can be added.
You probably need to actually add the reference to the dll in your project.
see the following link for details
http://msdn.microsoft.com/en-us/library/wkze6zky.aspx
(The System.XML, and System.XML.Linq should be in the .Net tab)
Related
I'm in C# land today. I'm trying to write a function which accepts a user agent string and returns an object that gives me at least the browser name and version. So I tried this answer, but apparently I don't have access to HttpBrowserCapabilities. It tells me the type or namespace name could not be found (yes, even if I add using System.Web, it still doesn't show up, or when I type using System.Web. it doesn't pop up, so it's obviously not there).
I'm using .net 3.5, but the documentation for that class shows it existed even in 3.5, so I'm not sure what's going on. I have access to the browscap files - ini or xml. Am I going to have to write this from scratch?
Edit: I've fixed the reference problem. But Chrome is being reported as AppleMAC-Safari 5.0. I'm wondering if I'm going to need a completely different approach. PHP figures it out with the same ini file fine.
Adding a using block does not automatically import the DLL. All a using does is allow you to not write:
System.Web.HttpClient //Or whatever
All over the place, and use HttpClient instead.
You need to add a reference to System.Web to the project before any of its classes will be available to you.
Did you have a using System.Web; statement in your source file?
Here's a tip: if you're using Visual Studio, and you have a reference to the System.Web.dll in your project, if you type the name of a type and press Ctrl-. it will give you a popup menu to add the namespace reference to your source file.
Do you see it in the ObjectBrowser (assuming you are using Visual Studio)? I found the namespace this morning (granted I'm on 4.5 - but documentation shows it has been around since 3.5 and earlier)
I am working on a C# PCL. The targets include Windows Phone, iOS, and Android (all via Xamarin). Whenever I add a new class, I get a popup starting with "The namespace system could not be added to the project." It then proceeds me to warn me that things might not work. Well, they do work, but the popup is annoying. Can I stop it?
I guess this is a problem with the Framework version of the namespace systemand your project.
Confirm they both match the same framework.
I recommend you take a look over this link, which addresses a similar kind of issue. Usually when the references are not proper, you may get this kind of issue.
using System.Runtime.Serialization;
using System.Runtime.Serialization.Formatters.Binary;
VS says, The type or namespace name 'Formatters' does not exist in the namespace 'System.Runtime.Serialization'. Well, I should add this reference. Click Project > Add reference > .NET, there I can see only System.Runtime.Serialization, nothing like Formatters.
System.Runtime.Serialization.dll appears to be under c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\Profile\WindowsPhone71\ - there are no Formatters, neither Formatters.Binary there.
How to find this reference?
The BinaryFormatter is not supported in Silverlight (or Windows Phone).
So apparently Silverlight does not have the BinaryFormatter. However an open source project exists that may be able to provide similar functionality for you. It is called sharpSerializer. It will work with Silverlight and WP7.
I am keeping the other half my answer below, while not appropriate for Silverlight, may be helpful for those that are still missing said reference in other projects, as it should correct it.
For other projects that do not use Silverlight, and have access to the BinaryFormatter you may have your target framework set incorrectly.
Make sure you are using the full .NET Framework 4 Profile and not the .NET Framework 4 Client Profile in your project as your target framework. See the image below, you can find these settings in your project's properties.
I'm trying to access System.Collections.Generic.Stack<> in Visual C# 2010 Express, but the IDE (and compiler) claim that it's not present. Several other classes are also missing, including LinkedList<>, SortedList<> and Queue<>. I've checked the documentation for both the System.Collections.Generic namespace and C# Express, and can find no reference to any deliberate limitations.
Oddly enough, if I sort the documented contents of the System.Collections.Generic namespace alphabetically, everything after List<> is missing, but that may just be a very weird coincidence.
Edit:
I tried a commandline build using MSBuild, which also complained with error CS0246. However, using csc worked.
Followup:
I tried removing all resources from my project and adding a stub class which just created an instance of Stack<>. Not only did that work, everything still worked after adding the old class back in and removing the stub. I can only assume there was some kind of caching silliness going on. Very annoying. I'll re-open if this issue reappears.
I expect that your project is missing a reference to System.dll.
Check whether "System" is listed under "References" in the solution explorer. If not, right-click References, choose "Add Reference...", and add a reference to "System".
Note: List<T> is in mscorlib.dll, and all collections that are alphabetically after List<T> are in System.dll, which is why I think this is what's happening.
I hit this weird namespace issue when adding my first 'Service Reference' to a client project in Visual Studio 2010.
If my project's default namespace uses two or more parts, e.g. MyCompany.MyApp then when adding a Service Reference a Reference.cs file is created containing the namespace MyCompany.MyApp.ServiceReferenceName with a lot of auto-gen code with fully qualified names, e.g. System.SerializableAttribute, System.Runtime.Serialization.DataContractAttribute.
The Reference.cs file will be full of compilation errors because the compiler starts treating the System namespace as sub member of the MyCompany.MyApp namespace. You get an awful lot of errors along the lines of:
The type or namespace name 'Runtime' does not exist in the namespace 'MyCompany.MyApp.System'...
If I amend the namespace at the top of the Reference.cs file to something simple, e.g. MyCompanyMyApp.ServiceRefernceName then the compiler behaves and recognises the System namespace references as decleration of .net's System namespace.
I'm using a different workaround for now as I really want to keep my multi-part namespaces. My current alternative is to append global:: in front of the System namespace references to force the complier to do the right thing. In fact, if the 'Add Service Reference' wizard uses T4 templates I may just amend those to embed my workaround at the source.
Questions
I'd really like to understand what's going on here and why a multi-part namespace causes this issue. Presumably there's more to namespaces than I thought. Secondly, would really like to work out a better solution than performing a global Find/Replace every time I add a Service Reference or mucking around with some T4 templates.
I found the answer here somewhat unclear, so I thought I would add this as an example (I would do it in the comments but it looks better here):
So I have this as my default namespace:
namespace RelatedData.Loader
But I also add a class named:
public class RelatedData
{
}
Because the class name matches a portion of the namespace when it generates your proxy with Add Service Reference it gets confused.
The answer here was to rename my class:
public class RelatedDataItem
Ahh well I found the cause eventually.
I'm working against a very large third party WCF API and ... one of their namespaces is LameCompany.System (!!) Carnage then ensues...
Arrrgghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
The lesson to learn here is when Visual Studio/.net compiler stops recognising the BCL's System namespace you have a namespace/type in your project called System. Find it, remove it, shoot the developer that created it.
I found that having a class name similar to your namespace causes this.
Try renaming your class name
I ran into a similar issue with VS2012 described by jabu.hlong and Simon Needham after minor changes in the client project that has the references to the WCF services after updating the reference to the services. I got lots of errors compiling the Reference.cs files generated and so on (the generated files of the XAML as well).
I have selected to reuse types from specific assemblies in my solution and got a similar problems with the namespaces.
The error I get is that the namespace of the reused assembly and the namespace of the generated types can not be found when used in the Reference.cs. Both namespaces have in common the first parts, as they are from the same solution. My namespaces in the solution are like appname.tier.technology.project. Both conflicting namespaces are Appname.Dto.Modulename (the reused assembly) and Appname.Client.Wpf.ServiceName (the namespace in the client project using the services for the generated types).
The problem arises after a minor change in the client project, when I created a new utility class in the namespace Appname.Client.Wpf.Appname. I choose that namespace because the Appname is also the name of a module in the client project. This seems to confuse the compiler and can not resolve both namespaces in the generated Reference.cs. After changing the namespace of the utility class to avoid using two identical parts in it and updating the service reference, the compiler errors in Reference.cs dissapears.
I tried different things (and tried different namespaces when adding the service reference), but nothing worked for me except this brute force fix - in my case it was OK but I am aware it's ugly (and needs to be repeated if you use "Update Reference" in the future):
Since the WCF service namespace is added to your default namespace, just search and replace all mentions of the newly added
MyNamespace.ServiceNamespace
with
ServiceNamespace
in the whole solution (use your own namespaces of course), including the auto-generated Reference.cs file.
Basically, the problem is a name conflict where one name is hiding another. A folder or class named "System" can do that, but if you also have a class with the same name as your project, you'll see the same thing. Sure, you can rename everything in the reference.cs, but it's probably better to rename your conflicting class.
I had folder in my project called "System" (yes, very stupid of me) and that caused some issues in the references.cs.
Renaming the folder (and the namespace), fixed the issue.
Here is how I solve this issue on VisualStudio 2017 trying to add a reference to a web service in a test project.
After trying adding the references, rebuilding, closing, reopening and spending some time on the issue, I noticed that VS had put the files it creates to reference the WS in a folder named "Connected Services".
I renamed the folder without the space then opened all the files in the folder and the csproj with a text editor, replaced all the occurrences of "Connected Services" to "ConnectedServices" and reopened the project.
I then added references to System.Runtime.Serialization and System.ServiceModel and everything now works fine.
This is a bug in Visual Studio (still is at version 2022). To fix, remove the namespace in the reference.cs file. So if your namespace is "myapplication" and your service is "myservice", you'll see myapplication.myservice in the reference.cs file. just delete "myapplication." everywhere and make sure it isn't auto-generated again (lest you have to re-delete everything).