We Keep Coding

Visual Studio doesn't put binaries of Unity project to output folder

I’m working on a solution containing default Unity project (Assembly-CSharp).
I added a test project to the solution with a reference to Assembly-CSharp. According to IntelliSense, the test project does see the types from Assembly-CSharp, however when I’m trying to build the solution, I’m getting the following error:
Metadata file 'MyProjectFolder\Temp\bin\Debug\Assembly-CSharp.dll' could not be found.
Thus, I'm not able to run unit tests on my Unity project.
Indeed, when I’m building the Unity projects, the .\Temp\bin\Debug folder remains empty even though the build is recognized as successful by VS.

The problem is caused by Disable the full build of projects setting which is new in Unity Tools extension. It prevents the binaries to be created, which speeds up situations when they're not actually being used, like when starting the debugger.
Turning this setting off in Visual Studio settings fixes the issue. Now all build products are placed in ./Temp/bin/Debug folder and I can run unit tests.
Feature request
I made a feature request to VS to make it possible to define this setting at solution level, so that you can have 1 solution for speed and 1 for unit testing. I hope it will get enough votes up: https://developercommunity.visualstudio.com/idea/798543/make-it-possible-to-manipulate-the-disable-the-ful.html

I have the same problem, and regenerate project files did the trick.
Edit => Preferences => External Tools => Regenerate Project Files

Update files in visual studio project from build script

Scenario
I am in a situation at the moment where one of the projects I am working on depends upon a 3rd party API, which exposes a swagger descriptor in JSON which we consume using auto rest to generate the C# files for use in the system.
The c# files are generated as part of the build script however there have been instances where the API is updated, and although we do not use any of the new changes it does change some of the c# code which is generated which in turn may depend upon new files which are output from the build script but VS does not know they exist so does not include them.
Issue
So I am trying to find a way to tell visual studio from a build script or some sane way (Without manually changing a *.csproj file) to automatically include everything within a folder in its project, so is there a way to do this?
Other Info
I have deliberately not mentioned build script technologies as it is not really important, so I don't mind if I have to use msbuild tasks or other command line stuff as long as it works I can probably find a way to hook it in.
Also I know some people will think "why do you need to keep re-generating the files?", and we don't really, and currently we try to keep to a specific version, however ignoring that the question still stands, i.e how do you update files VS knows about from outside VS.

You can use wild cards in .csproj file. You only need to do this once
since you didn't give the folder name, I am suggesting a generic solution for you.
To prevent the Visual studio from expanding the wild card once you modify the porject list in Visual studio, you have to add it as property.
In PropertyGroup , add a property with like this
<PropertyGroup>
<IncludeFolder>yourFolder\**</IncludeFolder>
</PropertyGroup>
Then in add the following line to ItemGroup
<ItemGroup>
<Content Include="$(IncludeFolder)" />
</ItemGroup>
This will add everything in that folder to your project.
Also this wild card will not be expanded by the visual studio once you modify them from Visual studio solution explorer. (A weird process from Visual Studio)

Compiling C# Code at Runtime [Update: or Alternatives]

I'm trying to develop an Application in .Net4, that creates a custom Window, inserts custom controls and saves it in a directory. My next challenge is how I can generate/build additional code from my Visual Studio Solution in a WPF .exe Aplication. I need only some classes that will be generated and transformed to a .exe. This classes will give the logic to navigate from one Window to another.
Here is a little diagram that I did for the question:
Things that I have researched:
CSharpCodeProvider: I can pass some classes in a string[] but I don't know how they will work with dependency, or when a error/bug occurs it will be difficult to see where the error is. And finally worst thing is that I can't set a location to build this .exe. It's built in the main Solution/Bin/Debug.
MSBuild: Here I can set the location where I will build the solution, but for this I need an extra Visual Studio Solution. What I'm trying to do is to have inside my Application a Build button that can build like in Visual Studio a .exe program but with custom classes that I will have in my Application.
I don't know if its possible, I was looking for it but I'm a little bit lost. I see in http://www.icsharpcode.net/opensource/sd/ that the have a builder, and they can set the location and build a .exe from the code. The only difference from SharpDevelop is that my controls and Window are customs.
UPDATE:
Maybe what I'm trying to do is better with other tools. Maybe compiling C# in runtime is not he best way. I will appreciate another ways to solve the problem.

What I do is Creating a new extra project for this .exe and must just copy/paste this .exe to each Project location.
But this is not very useful, if every time we must copy/paste this .exe
I just searching or a solution. I made this as a alternative solution but I don't like it so I will continue to investigate for a generation tool or something else.

A pain-free way of debugging a "plug-in" application?

I'm about to start developing a desktop application (WPF) based on a "plugin" architecture, and was going to use MEF (and its DirectoryCatalog) to discover and load plugin assemblies. We're going to be developing many plugins, so it seems sensible to keep them in separate VS solutions rather than bloat the "core" application solution, but having only ever worked on single, standalone solutions, I suspect this is going to make debugging a bit tricky. I'm using VS2013 if that makes a difference.
I'm assuming that I'll still be able to step into a plugin in scenarios where the "core" application calls a method in that plugin? And I'm guessing that once in there, I'll be able to set breakpoints in those source code files that have been "visited"? But what if I want to add a breakpoint to a different source code file - one that hasn't been visited while stepping-through? How can I open that file? In a single solution I could just open it via Solution Explorer, but not (I'm guessing) when it's in a separate assembly.
I'm trying to pre-empt any problems I might have with this multi-solution approach, and wondered if VS had any clever features to simplify some of this stuff. Having separate solutions also means first compiling the plugin solution(s) that I want to test, then compiling and running the "core" application solution. While it's only a couple of extra mouse clicks, are there (again) any VS features that could help here?

This is a common scenario and not tricky at all.
In the project properties of your plug-ins, go to Debug -> Start Action and set Start external program to the executable of your core application.
This way, you only have to compile your core application once (probably using a build script that just builds everything), and debugging a plug-in will start the core application with the debugger attached and you can debug the plug-in (as soon as your core apllication loads the plug-in assembly).
Also keep in mind that you can dettach the debugger from the running application, switch to another instance of Visual Studio with another solution opened, and again attach to your running application. This comes in handy if you e.g. debug your plug-in and want to set or use existing break points in your core application.
As long as Visual Studio is able to find the debugging symbols (the *.pdb files), stepping through the code of e.g. your core application while debugging your plug-in is also no problem.

I see two ways to do this.
The more comfortable option:
1. You can add the external solution to the core solution.
Walkthrough: Adding an existing Visual Studio solution to another solution
By doing this you can organize your solution to reference the code and still keep each plugin solution separate at the same time.
You just reference those plugin solutions from your core solution that you currently want to work on. Also, using this approach you can organize the other solutions just like you would with normal projects and move thembetween virtual solutios folders to your liking until you have the most adequate folder structure.
Quote from the article:
The nice thing about this approach is that not only are all the
projects now in one solution but at any time, you can open the
separate solutions without impacting the "master" solution and vice
versa.
The files in the references solution can be opened and edited just like any other file from your "normal" projects, and of course, you can set breakpoint like in any other code file, too.
This way you can both edityour code and step through it, which I personally find much more convenient than switching and attaching to multiple processes.
2. Add the PDB files.
Put the DLLs with their corresponding PDBs of those plugins you want to debug into a folder and configure your core application to use that folder for the DirectoryCatalog. This enables you to step into the plugin code, but you will not be able to edit them.

#Andrew
Regarding debugging, it shouldn't be an issue as long as you drop the .pdb files with assembly in directory which you are using as DirectoryCatalog.
Regarding building plugin solution before Core- as you have 1 build file for each solution, you should check if you can write msbuild commands in a .bat file to get it executed one after other.

Besides all the above suggestions, another way to debug is to attach your addin solution to the running core process. Attach to Running Processes with the Visual Studio Debugger

Weird: C# Type or Namespace name could not be found - Builds successfully

I have a weird error showing up in my project when it is open in the VS2012 IDE. Everywhere where I make use of another referenced project it suddenly says "Type or Namespace name could not be found". And by "says", I mean it has the text underlined in red with the error when I hover over it. The intellisense doesn't work for that code. BUT (and here's the weird part), the errors do not show up in the error console and the project builds and runs fine.
I can even debug and step through the code and it works perfectly fine. So at runtime the project is referenced fine but at design time the IDE can't find it. This worked for the past 2 weeks, and only then suddenly went a little bonkers. It's really annoying because I am rubbish at coding without intellisense!
Has anybody ever seen anything like this or have any suggestions?

I had this. I referenced assemblies whose "Target Framework" were set to ".Net Framework 4" in the "Application" secion of the projects properties. I changed this to ".Net Framework 4.5" not just in the referenced assembly's project but also the project I was building and it worked. Give this a try.

I have found this is a known problem with VS2012. Check to see how you are building, 64 bit or 32 bit. It won't work with 64 bit but it will with 32 bit. It will say things are missing and design will not work, however the program will run fine. I have heard the new VS update that hasn't been released yet will fix it.

Manually delete all the references to the libraries of the other projects and re-add. Intellisense rebuilds whatever it needs at that point and doing this has helped me in the past.

Another source of this problem is a solution with multiple projects containing code for the same namespace. The compiler can handle this. Intellisense won’t.

Related to a couple other answers here, I had a "Data" project using a "Data" namespace. Built fine, but just started recently showing errors from intellisense (even though it continued building fine.) (VS 2015.)
I fixed this by changing my "Data" project and namespace to "MyCompany.Data".
Oddly, the problem didn't seem to show up until recently, but making the change did fix it. Presumably there was a conflict in namespace with another project or reference, which can build fine, but intellisense can't handle.
You can change this in the Application tab of Project properties. You can also open up an EDMX diagram, right click, choose model browser, choose the second collapsable item in the model browser tab, hit properties, and there you'll find the Namespace option for generated Entity Framework entities and contexts. (Similiarly, if you modify an Entity Framework Model's namespace, you might also need to change the related connection to match [in Web.Config for ASP.Net and MVC.])

Make sure that there is no class with the name same as Project default namespace.

make sure that you don't reference .net framework 4.5 projects in .net 4 projects!

Examine your .proj files in a text editor and make sure the paths to your references are correct.

This can also happen if you set the Build Action to "None" on the referenced file and forget about it.

I had the same problem, where it would build and run fine, it just would always show that error and I couldn't use intellisense with the class.
I actually used the automatic method of creating the class in a new file to resolve the issue, then just copied the code over from the real class. I deleted the old file, renamed the new file, and now it works.