When I type in the autocomplete/intellisense for Visual Studio, if the thing I'm trying to reference isn't part of the current namespace, it won't show it at all.
Is there a way to get the Visual Studio autocomplete to include the names of classes that are in my solution, but not necessarily in my current namespace? This would be similar to how the autocomplete for Typescript works in VS Code - it lists things that match what you type, then automatically imports them upon completion.
IntelliJ autocomplete for Java also works the way I'd like it to - when I start typing, it gives me a list of all the various things that match, including their classpath, so I can pick the one I need.
If this is a thing for Visual Studio, I can't figure out how to configure it to do this.
ReSharper you will do the job (expensive but powerful).
https://www.jetbrains.com/help/resharper/Coding_Assistance_Code_Completion_Auto.html
If you need just to extend VS intellisense you can try this one:
https://marketplace.visualstudio.com/items?itemName=Dreamescaper.IntellisenseExtender2019
With Visual Studio 2019 now there is an IntelliSense option to "Show items from unimported namespaces" to achieve similar functionality to ReSharper. You still need to have added a reference to the project though.
I believe the issue is due to a lack of a reference from one project to the other. In the project you're working on, you have to manually add a reference to the project you're trying to reach.
Right-click the project node in Solution Explorer > Add > Reference > Projects > (your project name)
Then in the code, you probably want to include a using statement to reference the namespace and classes. Something along the lines of: using YourNamespace; using YourNamespace.YourClass; and so on depending on your needs.
But with the reference added, VS should be able to find the namespaces (similar to adding an external library).
The thing to keep in mind is that IntelliJ, and the autocomplete features in VS Code work much differently than Intellisense for C#. The former basically just looks through the code for similar usages, and infers from that that it's a potential member/function of what you're referencing. You'll see this in regular text editors like Atom and whatever. Autocomplete for C# is much more involved and VS does a lot more with reading the actual code and is less about inferring. I'm guessing this was done because it's easier for them to implement just based on the nature of the languages.
Related
Coming from Java world and now learning .NET 7 development in addition, I'm embarrassed to say, I cannot figure out how to open/view relevant API Reference documentation from within the IDE.
When I right-click a Dependency (Package) in Solution Explorer, I would expect an option to open the documentation which accompanies the given NuGet package. In short: How to open this documentation? (i.e. not for a specific class, but for a package as a whole)
When I right-click a namespace in say a using Foo.Bar directive in the code editor, I would expect an option to open the documentation for Foo.Bar (show of classes, etc). I cannot find such an option.
If I hover over a class name or right-click a class I would expect an option to display documentation for that class (its description, which methods does it have?, which properties? .. and so on).
I understand as much as that the equivalent of JavaDoc is some XML stuff which is typically bundled with each NuGet package. It is basically this that I would like to browse in HTML form. Or some other form which provides me an overview of which classes and interfaces exists, their methods, cross refs, and so on.
I'm aware of the F1 option in the code editor. However, it only works for stuff which is from Microsoft (it does an MSDN search).
For all the packages I use, I can see the XML file exist on disk, so for sure it is there.
I use various third-party libraries and some of them are kind enough to publish API Reference documentation on their website .. if you can find it. It all looks slightly different in terms of skin (I can live with that), but there doesn't seem to be a convention for how this documentation is made available to the library user as I'm used to in Java world. So I need to hunt for it?
Please help a newbie.
IDE: Visual Studio CE
Language: .NET 7
I can see that this would be helpful, but what you are looking for doesn't exist. There's no centralized location for the documentation of non-microsoft packages. So if you want an overview over the classes of such a package, it's best to google for it (or visit the project's github page).
There are several ways to get to the information you want/need:
If you want to know the methods/properties of a class, just type a dot after an instance of the class to see the possible elements in a menu. If documentation exists, the description of the different methods will also be shown, together with the required parameters.
If you want to know about all the classes in a namespace, you can do the same, just explicitly type the namespace to get the list of classes.
Of course, you can also use a tool such as Ildasm or jetbrains dotPeek to get the class structure of an assembly/nuget package.
None of this is really a HTML documentation, but as said, that only exists if the package providers generate and provide it.
I've been using http://www.codeproject.com/Articles/30035/Simple-WPF-Localization project to localize an app because (well) it's simple and straight-forward and supports dynamic language change.
I put all the language resources in the main project (i.e. resources.resx, resources.ja-JP.resx). That way the satellite assemblies get generated automatically and into the correct folder structure.
However, i would like to put all the language resources (except the default/neutral one - resources.resx) in a separate project. With that, i don't need to rebuild the main project (which has the application source) if i only needed to change something in one of the translations.
So, i would like to know if there is a standard way (or at least a very straight-forward way) of creating a VS project that only contains language resources.
I already tried creating an empty project and setting the output to class-library and the assembly to match my executable's name. It does create the correct satellite assemblies in the correct folder but it also generates a dll. It would be real simple if there's a project-type for c# or wpf that are completely language resource-only but i can't seem to find any references about it.
(btw, i'm using VS 2010 with WPF project)
thanks for any help!
(late reply, but for the community)
Depending on exactly what one want to achieve, building satellite assemblies from the command line might be the ticket for you (using command line tools resgen and al.exe).
I had to do this to enable non developers to modify resources, and without going through the development team/build/deploy cycle, have their changes take effect and allow them to validate.
This is mentioned in a lot of places in the MSDN docs, but I haven't seen many end-to-end samples demostrating it:
https://github.com/JohanPGunnarsson/LocalizedResx
I've been teaching myself C# for the past couple weeks, and as someone whose IDE of choice is Notepad, I'm having a little bit of difficulty transitioning to Visual Studio (I'm using 2010 express). In particular, I'm wondering how the organization of the Namespace-Class-Method hierarchy manifests itself VISUALLY in the interface. I'm having a hard time making sense of it, and, more importantly, how to use the interface to effectively organize and keep track of my projects.
For instance, there's the "solution explorer", but there's no such thing as a C# "solution" (that I'm aware of). I suspect it's Microsoft's marketing speak for a more generic development term, but I can't figure it out. I get the option of creating New "projects". Is a "project" a "solution"?
I'm also a little fuzzy on namespaces. I suspect that the namespaces are the equivalent of a class library in Java. What are some examples of how namespaces are used in the real world? Say, for instance, I'm developing a personal finance application. Would I put EVERYTHING related to that application in one solution? Or would I create as namespace for, say, cash accounts and a namespace for investment accounts?
Within the namespaces are my *.cs files but I can't seem to figure out how to create a NEW *.cs file in my namespace. I would EXPECT, based on the explorer hierarchy, that any class using a namespace would appear in that list, and I would be able to use it as needed. For instance, I would be able to create enterDeposits.cs and enterWithdrawals.cs WITHOUT needing to create a new project.
I've found a couple tutorials online that tell me how to do things (like creating a new project), but without a solid understanding of the IDE's vocabulary, I'm not really sure I'm keeping everything organized as well as I could. Help!
Solutions and projects in Visual Studio are ways to organize code - they are containers used by the IDE to issue commands to the compiler and other build components as needed.
Solutions contain projects - projects contain code files.
Each project will compile to a separate DLL or EXE, a unit of deployment.
Namespaces can be spread across projects and solutions and be in different DLLs/EXEs. They are units of logical separation.
In Visual Studio, you can set a base namespace for each project in its properties. By default, every directory you create will get appended to that as part of the inner namespace. Any source code file created in a directory will by default get that namespace.
In general, namespaces are a pure code construct.
In a C# file, you have a namespace declaration - this can be any valid namespace identifier and can be in any project/solution/code file.
I do suggest taking a look at MSDN - it is a good resource for anything C# and Visual Studio.
Solution and Project Basics
Creating Solutions and Projects
Your first question has already been answered here: Visual Studio Project vs. Solution
You can find plenty of information about your send question here: namespace (C# Reference)
Great overview by Oded. RE: would EXPECT, based on the explorer hierarchy, that any class using a namespace would appear in that list, and I would be able to use it as needed. you are correct, the IDE will recognize classes in the SAME namespace.
One thing that tricks up new users is that namespaces do not inherit. If you have a namespace MyProject and another namespace MyProject.SubNamespace, the compiler will not automatically link the SubNamespacetwo. You need to specify a Using statement, e.g. "Using MyProject.SubNamespace" to let the IDE know to use the classes in that namespace.
I have a C# console application in Visual Studio 2010. It has a Main() method as well as a bunch of utility classes. I'd like those utility classes to be available to other solutions. From reading online it seems that I need to compile it as a Class Library (DLL). So here's what I did:
Went in Visual Studio to "Project > [ProjectName] Properties > Application" and changed "Output type" from "Console Application" to "Class Library"
Rebuilt; ProjectName.dll was created in bin/Debug.
Created a new Console Application
Solution Explorer > Add Reference > browse to ProjectName.DLL, select it.
However, neither IntelliSense nor the Object Browser could find the classes inside that DLL.
I tried recompiling several different Console Applications as Class Libraries and got the same result. I also noticed that it works if I initially create the solution as a Class Library, but not if I convert it to one later.
Any tips?
You do not need to build it as a dll. VS 2010 (and IIRC 2008) allow referencing exe assemblies. All you need is for they relevant types to be declared public - top-level classes defualt to internal if you don't add a specifier.
You can switch output type to Class library in project properties as well - then you will have an output as dll instead exe file
What I've always done (since this is what you do with C++ static libraries, which is what I normally use - though I think it has some advantages for C# too) is add the class library's project to the solution, then add a reference to it in the project (or projects) that uses it.
When you go to add a reference, the list of potential references includes items from the solution, so it should be fairly obvious what to do. You should then get intellisense for your library.
One advantage of doing things this way is that if you need to edit files in the library project, it's very straightforward because they are close to hand, and the project then gets rebuilt automatically when you compile the solution.
Make sure that the classes in your dll project are public.
At first, from the point of view of managed libraries it does not matter what kind of Output type is your managed library. I mean that you can successfully reference ConsoleApplication1.exe from ConsoleApplication2.exe project (so you have no reason to convert ConsoleApplication1.exe to ConsoleApplication1.dll).
At second, I've tried to reproduce your situation, but... without effect. My VS displays types/methods from ConsoleApplication1.dll. One reason I can suppose is that you have forgotten to set visibility modifier (public keyword) for your utility classes.
I'm using Visual Studio and COM with C# for the first time and there's something I don't quite understand about the 'references'. How do you know what to reference with a given 'using something.something'? The .Net references seem fairly simple, but COM is less obvious. I'm running Visual Studio 2005 and have the latest VSTO installed, but for the life of me, I can't figure out what I need to reference to satisfy:
using Microsoft.VisualStudio.Tools.Applications.Runtime;
There are a few Microsoft.VisualStudio things in the .Net tab, but none that continue with .Tools or anything like it. I feel like I'm missing a key concept here.
There are two issues here -
First, a reference doesn't necessarily correspond to a namespace. A single reference can contain multiple namespaces, and a single namespace can be shared by multiple assemblies which would need to be referenced. Needing to include a reference allows you to use specific types, not entire namespaces.
Second, this is something you'll need to know in advance. If you're using Microsoft's classes, such as the ones in the namespace you listed, MSDN can be a great help.
For example, take Microsoft.VisualStudio.Tools.Applications.Runtime.ServerDocument
If you look at the MSDN page for this class (in that namespace), near the top it includes:
Namespace: Microsoft.VisualStudio.Tools.Applications.Runtime
Assembly: Microsoft.VisualStudio.Tools.Applications.Runtime (in microsoft.visualstudio.tools.applications.runtime.dll)
This specifically tells you which assembly is required.
That reference is part of the Visual Studio SDK. I am currently using VS 2008, but the assemblies should be the same for VS 2005. The link for the SDK is here.
Going the other way is pretty easy. If you're given a reference, you can open that reference in the object browser to see what namespaces it contains, and from that, determine what usings to add. Its not trivial to determine what to reference for a given using, as there's no guarantee that there exists exactly one DLL for each namespace. How is it that you arrived at a
using Microsoft.VisualStudio.Tools.Applications.Runtime;
Without knowing what to reference? If its a code sample somewhere, they ought to mention what the external references and dependencies of the project are.