We Keep Coding

VS 2019 C# intellisense not suggesting references from within solution

I'm new to programming so I might not be using some of the correct terminology. I'm running into an issue with InteliSense when calling a C# class from another project within the same solution. It's not suggesting a using statement and is instead trying to get me to create a new class inside of the current project which is not what I want. I am having to go in and add a refernce to the project and then add the using statement in order to get access to the class.
I looked at some of the documentation online and nothing has helped so far. InteliSense appears to configured correctly to suggest using statements. It provide suggestions just fine. I've been able to create lists and then use it to add the proper using statement along with some other things. Just doesn't want to work with anything inside the solution. I've been following a couple of different tutorials including, .net core 2.1 and 3.1, inside MVC and Razor page projects along with a couple just straight C# console apps. It doesn't work in any of them when I start adding multiple projects to the solution and try using classes from outside the current project.

I am having to go in and add a refernce to the project and then add the using statement in order to get access to the class.
That is the correct behavior. In order for ProjectB to use classes defined in ProjectA, you must first add a reference to ProjectA. Just having the projects in the same solution is not sufficient.
The purpose of having multiple projects in the same solution is simply for grouping related code. The projects may or may not actually depend on each other. For example, a web application may have a separate projects for the actual web UI (the pages themselves), a data access layer, unit tests, maybe some class libraries for shared code used by multiple projects, and maybe even console applications (or some other project type) for performing backend administrative tasks. In this scenario, the web UI and console applications may have references to the data access layer project and/or the class libraries. The unit test project will have a reference to the web UI project, and so on. The dependencies are one-way - you may not have circular references (the unit test project has the web UI project as a dependency, but not the other way).

Setup Project for two applications that share dependencies

I am using Visual Studio 2008
I have two applications (AppA and AppB) that I what to be installed using one msi-installer.
Both applications have reference AppC.
This is what I did:
I created Setup Project
I created two subfolders inside of Application Folder (AppA and AppB)
I added Project Output for AppA into related subfolder
I added Project Output for AppB into related subfolder
Problem: AppC did not appear in subfolder for AppB. It looks like dependency can only appear once.
Could please tell me how to resolve this?

You should be adding "Primary Output from AppC" specifically to each of the application folders. This version of VS Setup does not appear to detect that the same dependency needs to be included in two application folders.
There are a lot of recorded problems with the VS Setup and Deployment project, especially in regards to dependency detection. Also consider that MS has stopped shipping this project type, and has chosen the ISLE as its replacement (I would recommend using WIX instead - its free and is a more modern toolset when compared to Flexera's offerings).
A merge module is overkill for a single assembly. If you had a package of assemblies that need things like COM exposure or other group behavior things that you dont want to repeat (and possibly get wrong), then a merge module is more appropriate.

NuGet to manage versioning of internal assemblies - DLL Hell

Background Information
I have taken ownership of 3 websites that share a number of internal assemblies, they each connect to a WCF Service hosted in IIS for basic CRUD type operations.
A couple of different developers could be working on each website at any one time, making changes/additions to the code that is used in the shared assemblies.
The Issue
Each developer then builds their code and ensure that their website is working correctly. However they are unaware that in changing the shared code they could have affected the functionality in the other websites.
To resolve this, I could build each shared assembly separately, copy the dll to a directory specific to each website and add a reference from there.
However this flags up a couple of issues:
This means constantly building the shared assembly and manually copying the dll to the directory it is required in.
When a developer gets the latest source code for the shared assembly, they get the changes any way.
I have thought about managing this using nuget packages, but this only really addresses issue #1 to make it slightly easier to manage specific versions.
I hope this makes sense...
Does anyone else have any advice/tips?

There's no real magic bullet to this one.
Either the developers have to take some responsibility for ensuring changes to shared assemblies don't impact other code that references those assemblies or you really shouldn't be sharing them across projects. If the things they're changing in these shared assemblies really happens that often, you might consider migrating those parts or the methods they're changing to each individual project. Sharing assemblies like this should really only be done for absolute core functions that should change very, very infrequently.

How can C# use a legacy DLL simply without registration(regsvr32)

Situation
I run a build system that executes many builds for many project. To avoid one build impacting another we lock down the build user to only its workspace. Builds run as a non privileged users who only have write ability to the workspace.
Challenge
During our new build we need to use a legacy 3rdparty DLL that exposes its interface through COM. The dev team wants to register the build(regsrv32.exe) but our build security regime blocks this activity. If we relax the regime then the 3rdparty DLL will impact other builds and if I have two build which need two different versions I may have the wrong build compile against the wrong version (a very real possibility).
Question
Are there any other options besides registration to handle legacy DLLs which expose their interface via COM?
Thanks for the help
Peter

For my original answer to a similar question see: TFS Build server and COM references - does this work?
A good way to compile .NET code that references COM components without the COM components being registered on the build server is to use the COMFileReference reference item in your project/build files instead of COMReference. A COMFileReference item looks like this:
<ItemGroup>
<COMFileReference Include="MyComLibrary.dll">
<EmbedInteropTypes>True</EmbedInteropTypes>
</COMFileReference>
</ItemGroup>
Since Visual Studio provides no designer support for COMFileReference, you must edit the project/build file by hand.
During a build, MSBuild extracts the type library information from the COM DLL and creates an interop assembly that can be either standalone or embedded in the calling .NET assembly.
Each COMFileReference item can also have a WrapperTool attribute but the default seemed to work for me just fine. The EmbedInteropTypes attribute is not documented as being applicable to COMFileReference, but it seems to work as intended.
See https://learn.microsoft.com/en-ca/visualstudio/msbuild/common-msbuild-project-items#comfilereference for a little more detail. This MSBuild item has been available since .NET 3.5.
It's a shame that no-one seems to know anything about this technique, which to me seems simpler than the alternatives. It's actually not surprising since I could only find just the one above reference to it on-line. I myself discovered this technique by digging into MSBuild's Microsoft.Common.targets file.

There's a walkthrough on registration-free COM here:
http://msdn.microsoft.com/en-us/library/ms973913.aspx
And excruciating detail here:
http://msdn.microsoft.com/en-us/library/aa376414
(the root of that document is actually here: http://msdn.microsoft.com/en-us/library/dd408052 )
Also, for building in general, you should be able to use Tlbimp or tlbexp to create a TLB file that you can use for building, assuming the point of registering is just to be able to compile successfully, and not to run specific tests.

Installation tools such as Installshield can extract the COM interfaces from the DLLs and add them to the registry. It can also use the self-registration process of the DLL (which I believe is what regsvr does), but this is not a Microsoft installer best practice.

in .NET COM is normally done thru Interop in order to register .DLL in .NET they are called Assemblies and that can be done several ways.. by adding references via VS IDE at the project level, or writing code that Loads and unloads the assembly.. by .Config file that haas the reference to the assembly as well as the using of that reference within the project... GAC.
If you have access to the 3rd party .DLL's you can GAC them, and reference them in your project
you can add a using to your .cs file header as well as add the reference to the project by right clicking on reference --> add Reference ...
you can also do the above step as well as set the copy local = true in the properties for that .dll.. I hope that this gives you some ideas.. keep in mind that .NET assemblies are Managed code so there are several ways to Consume those 3rd party .DLL's using other methods within C# like LoadFromAssembly ect..

Thanks for all the help.
We changed from early-binding to late-binding because we never really needed the DLL at compile time. This pushed the registration requirement from the build server to the integration test server (where we execute the installer which handles the registration). We try to keep the build system pristine and have easy-to-reset integration systems.
Thanks again
Peter

How do you package external libraries in your .Net projects?

A lot of my projects contain the Castle/NHibernate/Rhino-Tools stack. What's confusing about this is that Castle depends on some NHibernate libraries, NHibernate depends on some Castle libraries, and Rhino-Tools depends on both.
I've built all three projects on my machine, but I feel that copying the NHibernate/Castle libraries is a bit redundant since I built Rhino-Tools using the resulting libraries from my NHibernate and Castle builds.
Right now, I include all projects in seperate folders in my /thirdparty/libs folder in my project tree. Should I simply just have /thirdparty/libs/rhino-tools in my project and use the Castle/NHibernate libs from there? That would seem to make logical sense in not duplicating files, but I also like having each project in it's own distinct folder.
What are your views on this?

This is one of the problems that we're trying to tackle in the Refix open source project on CodePlex.
The idea is that Refix will parse all the projects in your solution, and before your project compiles, copy the necessary binaries from a single local repository on your machine into a folder within the solution tree and point the projects at them. This way, there's no need to commit the binaries. Your local Refix repository will pull binaries from a remote one (we're setting one up at repo.refixcentral.com), and you can set up an intermediate one for your team/department/company that can hold any additional software not held centrally.
It will also try to resolve conflicting version numbers - Visual Studio can be too forgiving of mismatched component version numbers, leading to solutions that compile but fall over at run time when they fail to load a dependency because two different versions would be needed.
So to answer the question "how do you package external libraries in your .Net projects", our vision is that you don't - you just include a Refix step in your build script, and let it worry about it for you.

I use a folder for each, which seems to be the convention.
Does it really make a difference if you're copying them?
What if you want to switch one out? Let's say you go with a new O/R mapper. It will be much easier to just delete the NHibernate folder than to selectively delete DLLs in your Rhino-Tools folder.
Take this to it's logical conclusion and you won't have any folder organization in your lib folder since everything uses log4net :)

Add additional probing paths to your app.config files to locate the dependency dlls. This way your can get away with having just one copy of everything you want. Though there are some quirks to using this feature (you must create the folder structure in a certain way). Look here for more details on the tag.

I will definetly recommend having a thirdparty or vendor folder in each of your project trees. If you find it annoying to have 32 copies of the rhino-tools package, you can have a single copy of it in your code repository, and do external references to it in your project tree.
Lets say you are using SVN, you can make a repository called "thirdparty libs" and in this have versioned copies of the libs. You then make an external property on your "thirdparty"-folder in your project tree which then in turn automaticly will do a check out of your centralized thirdparty libs. This way you for instance only have to update in one place if a security or a bugfix comes out, but each project is still in command of choosing which thirdparty libs, and which versions to use.
About the deps internally in thirdparty libs, i wouldn't mind those. The first time you compile your project, and some of the libs arent copied to your bin-folder because of implicit dependencies you can add an external attribute into your bin-folder, which will then automaticly check out the missing libs. That way you still only have to update your thirdparty libs in one place.