I have a WinForm application. I also have created my own User Control for it. Everything worked fine. Until today that I received the error message when I try to add it back to my program (I never removed it. Visual Studio did).
Failed to load toolbox item #UserControlName. It will be removed from
the toolbox.
I have it in my solution explorer but it vanishes from my toolbox after this error.
I also receive the warning that says:
'#UserControlName' is never assigned to, and will always have its
default value null.
And when I look at my designer code, that is true. But I haven't done anything with my designer code. My user control is defined there but not instantiated. How can I put it back?
Does it have anything to do with the fact that I changed my build platform from x32 to x64? If that is the case I will be surprised because the program was working fine after that change.
I was suffering from the same issue for one of our applications and could not find a solution. So I created the user and custom controls manually. After searching the web again I finally found why the designer is failing for this particular project. The answer is that project is 64 bit and Visual Studio is still does not have a 64 bit version, it is still 32 bit. So the designer could not load the controls in 64 bit applications or in class libraries. Read Microsoft's article about this.
There was an article on Visual Studio web site but it was removed. See the the answer in Visual Studio support forum.
https://social.msdn.microsoft.com/Forums/vstudio/en-US/77e10b58-43cc-4aab-919f-888f14f99571/x64-class-library-of-user-controls?forum=csharpgeneral
I had the same issue lately. As this (nor any other answer on this site and on the internet) actually helped me, I found out the way to fix it.
Just clean the files and rebuild the solution. As simple as that.
I was having same issue but I find the solution:
Click on "Project_Name" with left mouse and click "Build" then you can add the UserControl to your WinForm.
Change to AnyCPU and rebuild the project.
Visual Studio has problems with controls being 64bit.
You don't have to necessarily insert the user-control manually. I had the same situation an there was a reason for it.
In my case, it failed because the EXE assembly was compiled to 'mixed-mode' by using CLR support type /clr. After changing it to 'managed-only' by setting type /clr:pure, it worked.
For details, see my answer here at SO.
After many hours of head scratching with this problem with a large custom control with few changes from a previous working copy in source control I copied all the code into a new control name and file and it all worked.
This was to identify the problem line(s) of code since the debugger would not co-operate. The copied control (along with heaps of support code and modules) worked okay.
So these are the very simple steps that fixed my original code
In solution explorer rename the file (I just added an s at the end)
Rebuild
Test the control can now be added to a plain form
Rename the control back to its original name
Step 4 might be optional for you but if you have source control and it's a in a library you would want to do this.
This brought the control back onto all my forms that weren't working (so far as I can tell). It seems the problem is in VS that somehow remembers it doesn't like it?
Hope this helps and I hope I find this message next time I get this when I have forgotten the fix :)
P.S. Clean, rebuild and/or re-run the solution is the old stand by for this problem but this time it was just one custom control in a whole (DLL) class of them. Hope this helps.
For me, after adding the userControl, I rebuild the application first then refreshed the items on the tool box by going to projects => Refresh project toolbox items
Right click - Rebuild Solution fixed it for me!
Mostly caused by 32 bit / 64 bit architecture. Before Visual Studio 2022 the VS built in 32 bit, therefore cannot show 64 bit components.
Solution 1:
Create a new solution configuration in Configuration Manager with name: "Debug_FormDesign" or anything else.
Set the Configuration to the above name for all projects and set the platform to "AnyCPU".
Now open all projects Compile settings step by step, select the above configuration and change the Compile -> Target CPU option to AnyCPU.
Close all opened windows.
Clean solution.
Restart VS.
Select the "Debug_FormDesign" configuration in toolbar as active.
Rebuild solution.
Open the form designer -> Should work now.
You can easily switch back to the default "Debug" configuration after finish with the GUI.
Solution 2:
Use Visual Studio 2022.
At times like these, you'll be forced to tinker with the designer code. As long as you don't make drastic changes in the designer code, you shouldn't break anything. To play it safe, re-instantiate the object where the other controls are instantiated (near the top of the page). The designer should fill in the blanks for properties and such.
This should also return the control to the toolbox.
Check in your form.designer file if there is a left-behind property with that type.
It happened to me several times.
After I removed that line and rebuilt the project, everything started working.
In my case it helped to manually include the header files of the created user controls at the top of the Form where these controls are to be used.
Related
I'm not sure if anyone else has encountered this but often, when I open this particular solution, I see a whole list of errors (see below).
If I double click one of them, then Visual Studio seems to wake up and the errors relating to that particular cs file disappear. This isn't a critical issue and is more on an irritation than anything else but I wonder, is there perhaps something wrong with my code that's causing this false-positive or is it random Visual Studio behaviour?
I had this problem too.
Deleting bin and obj folders not work.
Cleaning solution not work.
Various platform I need to be as is.
Helped me close solution and delete folder .vs, which is often full of problematic mess. After opening solution all false errors disappeared.
As mentioned in a comment, you can do a Clean and Rebuild. If that does not work for you, you can browse to the solution folder and within each of the project folders delete the bin and obj folders. Then perform a build.
You may also want to look into your Configuration Manager and ensure that all of your projects are set to the same Configuration (Debug/Release) and Platform (Any CPU/x86/etc...) and marked to build for that configuration.
Finally, you may also want to check the Build Order for your solution. Ensure that projects are all built in the proper order.
-- Edit:
On thing brought up in comments that I will add here was to make sure that any library projects in the solution are added as Project References rather than referencing the output DLL directly.
Something that has only become evident in later years, and is only relevant upon reflection on this old question, is that the particular solution that we experience this issue in contains a Website project and NOT a WebApplication project. This became evident when we started to look deeper into these recurring errors and noted that they only ever related to codebehind files and all had to do with the Control Name not existing in the current context.
Amongst the various differences between the two project types, it seems that the lack of designer files for each ASP page may be a contributing factor. The error disappears as soon as you double click it potentially indicating that VS is not able to keep track of the control references until you open the relevant page / codebehind file.
We're moving over to a Web Application as a temporary measure.
Hope this insight helps someone else!
I have Visual Studio 2013 with no plugins or anything fancy. Whenever I'm coding, every so often (maybe once every half hour) intellisense randomly stops completing my sentences or popping up at all when I press Ctrl+Space.
I have tried Tools->Import and export settings->Reset all settings but it did not help. The issue came right back.
The only thing that solves it for me now is to close VS and reopen it. But as you can imagine, this is extremely frustrating.
I was having the same problem and this seemed to work for me.
http://omegacoder.com/?p=1008
Basically, go to Tools >> Options >> Text Editor >> All Languages >> General and make sure that both Auto list members and Parameter information are checked (not the half-checked/square state).
This is still happening in VS2013 update 4 (I have a WPF project using C#).
This was relatively easy to fix by closing then reopening the file not the whole project.
For me, Unloading and Reloading a project fixes MVC cshtml intellisense. Right-click project, click Unload. Right click grayed out project, click Reload.
Just to be clear, this problem only happens to me when in C# MVC views, only when checked into TFS.
I have also submitted this as a bug to Microsoft, see https://connect.microsoft.com/VisualStudio/feedback/details/932855/vs-2013-c-default-mvc-template-breaks-upon-checkin-to-tfs-2010
Looks like my issue cleared up after deleting the settings folder from my previous VS2010 installation. I followed the instructions here (Also applies to VS2013): http://www.haneycodes.net/visual-studio-2012-intellisense-not-working-solved/
In case URL breaks:
Open the start menu and type “%AppData%” and press enter to get to your Application Data Folder.
Either you were automatically placed in the “Roaming” folder or you weren’t. If you weren’t, go to the “Roaming” folder.
Open the “Microsoft” folder.
Open the “VisualStudio” folder.
Here you’ll see a folder titled “11.0” (the VS 2012 folder) and probably also “10.0” (the VS 2010 folder).
DELETE (or rename) the “10.0” folder. Note that you can now kiss your Visual Studio 2010 settings and preferences goodbye (your projects will be safe and sound).
DELETE (or rename) all other folders that are not the “11.0” folder, assuming you used to have Visual Studio 2008 or whatever.
Now restart Visual Studio 2012 and you should be good to go!
try to delete the .suo file of your solution. It worked well for me.
The first thing I should mention is that this hasn't happened since I've upgraded my RAM. I was at 4GB when this was happening. Often had multiple instances open as well as SQL Server.
I'm finding this seems to happen when I copy/paste controls on a page. Another side affect of this is that the designer.(cs/vb/xx) file is not updated right away and I don't have access to those controls in code behind.
I've tried a handful of things and here's a summary of what I've found so far:
If only 1 file/window appears to be affected, close/reopen that file.
If that doesn't work... in Visual Studio:
Click Tools->Options->Text Editor->All Languages->General
Uncheck "Auto list members"
Uncheck "Parameter information"
Check "Auto list members" (yes, the one you just unchecked)
Check "Parameter information" (again, the one you just unchecked)
Click OK
If this doesn't work, here's a few more steps to try:
If still not working, close all windows and reopen
If still not working, close/reopen solution
If still not working, restart VS.
(I haven't yet figured out why more drastic steps are required in some cases.)
For C++ projects:
MSDN has a few things to try: MSDN suggestions
The corrupt .ncb file seems most likely. Note that in VS2013 and later, it is the .sdf file, which can be found in the root folder. Try searching for filename:*.sdf.
From MSDN:
Close the solution.
Delete the .ncb file.
Reopen the solution. (This creates a new .ncb file.)
Notes:
Tested in VS 2013/2015
Logging possible causes:
Copy/pasting controls in a source page. I found that my designer.vb file didn't update from this, either.
Copy/pasting code from another page that caused an error because the code copied referred to a control that wasn't on the page I was pasting to.
C++ project has corrupt .ncb file
Like cacau says, you must first do a clean of the entire solution. Then restart VS rebuild the entire solution.
This sometimes happens when you are using Entity Framework or WCF services (Or the combination)
VS generates a lot of files then that contain code (the service reference for example). When you regenerate that code (And for example you are running a web project) sometimes you forget to stop the site. Then VS can't overwrite every file. Resulting in a global intellisense failure.
For me, the problem happens when I have two instances of same solution opened. On one of them I'm running Tests, while on the other I am making tweaks to code. Intellisense will quit working on me usually after I've run some tests and stopped the debug session manually.
The solution for me is to close all VS windows and reopen...
Did you try a clean build on your project?
VS might have become confused with some of its generated files..
None of the solutions in this thread worked for me.
what worked was that I deleted everything in the packages folder. when I rebuilt the solution, nuget got the latest versions of all the folders I deleted, and intellisense started working fine.
If I am not mistaken, the problem initially was caused by the contents of the "Microsoft.Net.Compilers.1.0.0" folder, but I dont know why.
If you have this problem in one file, make sure that this file is included in your project. Right Click the file, Select Include In Project. If the file is not included in your project, VS will treat it as a normal text file.
I followed the instructions given in response to the question : Visual Studio 2012 - Intellisense sometimes disappearing / broken (thanks to SajjadHashmi and others). I've copied the steps I followed (which worked for me) here in an attempt to be helpful.
1: Close all the tabs and open your file again. (Thanks to russds)
2: Clean the Build > Close the Solution > Restart Visual Studio > Open the Solution again
Further steps are listed if you follow the above link but some seem to no longer apply to Visual Studio 2013 (e.g. refresh Local Cache for intellisense).
I know that these steps involve restarted Visual Studio (which you are explicitly trying to avoid) but for those who find your question (such as me) a potential solution might be useful.
In case anyone else fell into the black hole I did ... I too suffered from this issue but NONE of the above solutions worked for me. Eventually I figured out that somehow the opening <body> tag had been deleted from my .Master page and that was causing all my .aspx pages to lose 95% of the Intellisense code hinting. Once I added the missing <body> back to my .Master page, the Intellisense finally started working in my .aspx pages again! Hope this helps someone ... just cost me 1.5 hours!
Sometimes none of suggestions here works - at least that happened to me.
But don't rush with configuration resetting, cleaning up visual studio configuration files and so on. If clean/re-build + vs restart does not work - problem might be in code itself.
In my case (vs2013) I had C++ class exposed in .h like this:
class MyClass: ...
{
....
DLL_EXPORT returnArgs function(InParameters)
}
where DLL_EXPORT is defined as :
#define DLL_EXPORT __declspec(dllexport)
Same function in .cpp:
returnArgs MyClass::function(InParameters)
{
}
vs2013 was refusing to jump between function definition / implementation.
Reason seemed to be DLL_EXPORT macro - I've written function like this:
DLL_EXPORT returnArgs MyClass::function(InParameters)
{
}
After that intellisense started to work again.
It's possible also to remove that define or wipe it out - according to visual studio documentation __INTELLISENSE__ - but that define did not work for me for some reason. Code snipet like this:
#ifdef __INTELLISENSE__
#define DLL_EXPORT
#else
#define DLL_EXPORT __declspec(dllexport)
#endif
Please comment if you understand why this does not work.
In vs2015 this issue seems to be fixed, but there are other problems with vs2015.
None of these things worked for me. After lot of struggle I found why it was not working for me. I always had multiple solutions open in my machine. For suppose, One solution is for front-end layer and another solution is for back-end layer.
When it hits breakpoint kept in backend service layer intellisense was not showing up. After I closed all other solutions and rebuild the solution where I wanted to debug, everything worked fine.
There could be other reasons, but this worked for me and wanted to let this community know and it may help someone.
EDIT: Few times "delete all breakpoints" and adding again worked.
I had the same problem and in my case it was the same file being open twice. For example I have dev\include\myfile.h AND dev\include\myfile.h\ (note the backslash, making this a unique string).
This happens when I use F12 to find a symbol in an include file, but also have the original .h file open already; Visual Studio opens up a duplicate file, which is really the same file.
When saving either of the two instances, the changed file date will be noticed and I get a popup asking whether I want to reload the other instance. More problematic seems that it also confuses IntelliSense. I just tried closing all duplicate instanced files, and IntelliSense started working again without restarting or reloading anything.
I tried to fix my problem by solution VS2013 Intellisense constantly stops working
But it did not work for me.
Solution that worked for me is off/on Auto list members
Go to Tools > Options > Text Editor > General
Why does Rebuild fail with no errors?
Since this morning, this error keeps showing up. I build the entire solution (25 C# managed projects) and a "Rebuild All failed" appears, but without any errors! (I have 13 warnings about COM not supporting Generics, but it's "normal" because one dll is exposed as COM.)
Not an answer per se - but you're better off looking at the output window and seeing what it says there.
Also, to help with that you might want to look at your MSBuild verbosity - as shown on this screenshot (last two options):
Beware - the highest level generates a MASSIVE amount of information.
Finally - running msbuild from the solution folder in a command prompt will really nail the issue - because error messages and warnings come up in red and yellow respectively.
I found my own solution and it is simple:
When this error occurs, save the project and close VS 2013. After that, re-open VS2013 and open the last project.
It works like a charm. But it is very annoying every time!
Many people reported this problem in VS2010, VS2012 and VS2013.
Could be a corrupt Solution User Options file.
Close the solution, delete its .suo (.v12.suo for VS2012+), reopen the solution, and Visual Studio will build a new one. You will lose the StartUp Project, breakpoints, bookmarks, which files are open, which projects/folders are expanded, etc. But that's all minor compared to the solution not building!
I had the same problem. I was trying to refrence a higher .net framework version(4.5.2) to lower .net framework version(4.5) which was causing build error. I made the version same in both projects and it worked.
Check the Output Window (View -> Output) as that will tell you what's going wrong. Sometimes a reference might be missing or there is an issue with the targeted version of .NET for one project in a solution.
Have you tried to clean the solution befor rebiuld it?
This is the list of checks & things I would do if I were you (try to build after each step):
Is error list activated? (Sometimes I forgot to activate and I can see only warnings & messages)
Check output window for error messages..
Clean solution.
Double check after clean that everything is deleted from debug folders.
Build it in release mode.
Build solution project to project until you isolate problematic project.
Remove COM and comment code to see if is this the source of problem.
Restart VS2010.
Restart windows.
Few moments ago I fix it with repair of .NET Framework installation (.NET Framework v4.0 Extended in my case).
I had the same issue in VS 2015. I tried the following with no success:
Close VS project and reopen
Close all open VS projects and reopen just the project that had the issue
Clean solution
Rebuild solution
Delete all files in bin\debug and bin\release
Lastly I tried Keith Robertson's answer, delete .suo (\Visual Studio 2015\Projects\[ProjectName]\.vs\[ProjectName]\v14\.suo). Although this didn't get me a good build, it did finally give me an error message stating that I had two entry points to my application. I went to application properties (Alt + Enter) and select a Startup object from the drop down.
This error seems a bit generic to me. I also went through this situation, but I managed to solve it differently than any of the ones mentioned here.
I have a project and several dependencies. And one of these dependencies has undergone a change.
When compiling the main project in debug mode, I verified that everything was ok.
However, switching to release mode and recompiling the problem occurred.Rebuild all failed and 0 Errors
By analyzing the debug output, I encountered an error:
Although the build dependencies are configured correctly. When compiling in release mode, the main project did not find the new method created in the secondary project.
So I had to recompile each secondary project one by one in release mode. After that, I recompiled the main project and everything worked.
Hope it helps someone!
I just had the same thing. For me, it helped to restart VS and run it as Administrator.
Select the appropriate target framework
- Right click on project
- Properties
- In application tab, Select the target framework
clean the solution
Try and build each project and see where the issue is.
Check each of the references (of each project) to make sure not have the yellow warning sign
Has the solution ever built?
I just had this happen to me, and realized that I left a '#error' line in my code and forgot about it. When I tried to build, the build failed but the #error line didn't show up in my errors.
Try searching all for '#error'
I fixed it on my new implementation of Visual Studio 2013 by going to the database project / Project Settings and noticing that the Target Platform was SQL Server 2014 instead of 2012 like it should be.
Once chance of getting this error is when we try re naming the service reference name, we give some other name in the service reference, but in the namespace some where it will be referring the old name, so if you delete and add a service reference then keep the same name, else we may face this error, but we can see the error in the Output window.
There are apparently many causes of this. I just found the cause of my issue: the .NET version of a new project I created was higher than the version of the top-level project. (4.5.2 vs 4.0)
I got a similar issue today, and fixed it with repair.
Start
Run…
Appwiz.cpl
(Find your installed Visual Studio version)
Right click
Change
Repair
In my case it was the wrong date and time of computer.
I was getting no feedback/messages/errors. Just that all projects failed to build.
I closed and tried again--I noticed an error saying "you are not authorized to access..."
I clicked on my account, re-entered my credentials, and rebuilt the solution.
Voila! I got what I am used to seeing when I build a solution -- plenty of errors in all their glory.
Hope this helps someone.
Here's yet another reason which may sound familiar to some. I had integrated some code into my solution that wrapped a DLL. The C# code file that came with it offered a nice managed API and handled the low-level LoadLibrary stuff to access the DLL. Both had the same base name, so I had SomeName.cs and SomeName.dll. I could just drop it into any project and it would work.
This wasn't so nice after a while as I started using it in different projects. I got copies of both the DLL and the wrapper code in multiple projects. So I figured it would be better to drop the wrapper code and the DLL into a new class library project and then reference that new project from other projects.
After I had done that, I started to get this issue. The build went well up until the very last stage and then failed without error. Output showed nothing but successes.
The problem was the name of the wrapping class library project. I used the same base name (SomeName) for this. By default the assembly name would be SomeName.dll and I already had one such file (the DLL to be wrapped), thus I had a conflict with output files.
After renaming the wrapping project and its output assembly to SomeNameWrapper, the problem went away.
This may not be your exact cause but it seems likely you have some name clash or deployment issue as well. And it is not surprising the compiler won't give you an error because there is no problem in the compilation phase, the trouble starts with deployment and apparently this does not come out in an obvious way.
I had the same problem the original poster was displaying with 0 errors and Rebuild all succeeded. The Output tab showed a message that a referenced dll was built with a higher version of the .NET Framework.
Changing the .NET framework to match resolved the issue I was having with 0 Errors and Rebuild All succeeded.
The solution:
Because Prerequisites not set for debug set only for release
01-Change solution configuration ( in main screen )
set (debug to release)
set solution platform to (Any CPU)
02-Set Prerequisites for debug ( If you want to continue in debug mode )
03-set target platform version for all Projects
Some of the files included in your solution are not in the correct directories, or you have changed the name of one or more directories in your application. In the solution explorer under Setup review the list of all files and remove those that are not properly listed in the SourcePath Property.
One of my dependency in View file caused this. Check your view files for any dependencies which is not injected yet.
I've created a C# WinForms application using VS2010. I'm new to creating user controls so I created a new user control (as part of the same project).
When I rebuild the project, the new control appears in the toolbox. And when I drag the control from the toolbox onto a form, I get the following error.
Failed to load toolbox item 'TagGroup'. It will be removed from the toolbox.
This happened the only other time I created a user control as well. I've searched the web but most answers I found seemed related to having the control in a separate assembly. (Note that I found plenty of questions with the same problem I'm having.)
Can anyone suggest where I should look next?
My application need to be 64-bit. In order to use custom user controls in the designer I just added a new project to my solution. This new project use the "AnyCPU" setting and contains all my user controls.
My solution contains the following projects:
MyApp which is my main project (Windows Form Application) compiled in 64-bit and referencing my second project
MyApp.UI.UserControls (class library) is compiled for "Any CPU" and contains all my user controls
Works like a charm and it's clean
By the way, there is a Microsoft support article about that issue.
Action: You attempt to use a 64-bit component within the Microsoft Visual Studio Integrated Development Environment (IDE).
Error cause: This behavior is by design. Visual Studio is a 32-bit process, and therefore can only execute 32-bit modules. While Visual Studio allows you to add a reference to a 64-bit assembly, it cannot actually JIT compile it to 64-bit and execute it in process.
Resolution:
Rebuild the assembly using the "AnyCPU" setting. This would allow
the component to run within a 32-bit process (such as Visual
Studio), or in a 64-bit process.
Add the assembly as a reference and load the control dynamically at
run-time. Although you still would be unable to use the
control within any designer inside Visual Studio, you can still
write the code needed to instantiate the control and set it's
properties accordingly.
Source: http://support.microsoft.com/kb/963017
I finally figured this one out.
The project I'm working with uses two class-library assemblies. Although these have nothing to do with the control I'm discussing, I looked and saw both libraries have Platform Target in the Properties|Build tab set to "Any CPU".
On the other hand, my application had this setting set to "x64". By changing my application's setting to "Any CPU", I can now place my user controls onto my forms.
Go figure...
I had this problem too, but the answer couldn't fit for me. My project has some issues it can only target x86 and x64 separately. In other words, I can't use AnyCPU configuration (that's because I reference different libraries for each configuration, since those libraries are not fit to AnyCPU).
The solution I came up with was: when I need to use the form designer, I change the setting to x86. Do the job, then set back to x64 and test. The problem occurs only with the designer, but the solution builds and runs fine.
I had this problem in VS2015 and the solution turned out to be simple.
I had created a user control by cutting and pasting a few existing controls from a form (with the aim of grouping them into the custom control). The custom control was okay (no compile errors), however the removal of the controls from the existing form meant that the application wouldn't compile. Of course not being able to add the new control meant that I couldn't update the code referencing the previous controls with code referencing the custom control.
All I did was hack and slash (commenting-out, creating temporary controls, etc.) so that the entire application would compile. After it compiled I found that I could drag the custom control onto the form (without the error that prompted this question). I then had to unhack and unslash so that the code properly referenced the new custom control.
Same problem here. I am guessing it is related to the fact that the VS2010 installed on x64 OS is still a 32bit program in the heart.
An alternative solution one might want to try is simply open TheFormThisUserControlIsSupposedToBeAddedTo.Designer.cs and use code to add the user control. Basically, you are doing the dirty work that the Designer is supposed to do.
It is not as difficult as it sounds, esp. considering that there are probably plenty of sample code in that file already (e.g. the buttons you added using Designer). The only difficult part is figuring out the right coordinates in the form to place the control.
The end result is that you can not see the user control in Desinger, but they are added on debugging/running.
I also experienced this problem but the cause was different. In my case a component (form) constructor or Load event invoked a method elsewhere that used reflection to find all classes that implemented a certain interface.
While that works fine at runtime, it generated the above mentioned exception at Design Time. (Type Initialization exception with a Type Load Exception as inner exception).
An hour of confused, weary troubleshooting at 3:36AM is again easily resolved with a fresh mind the next day!
I fixed a simple spelling mistake in the control's filename, so it now matched the UserControl name, cleaned and re-built and Bobs your weird uncle's cat. :]
GO project property then 'Build' tab and check 'Target Platform' was 'AnyCPU'.
I have a large windows application.
Recently when I make any change in the source code and run the project normally with or without debug, the changes are not made.
I tried to rebuild it, and everything goes fine,
now every change I made to the source code I have to rebuild the project then run it so that the changes are taking effect.
also I can't debug until I rebuild the solution.
my project is attached to source safe control.
any help is appreciated.
You frequently see this happen when a project gets deselected from the "Current Build Configuration" Dialog in visual studio. Try checking there to see if your project is unchecked. I think you can get to that menu by clicking the dropdown that says Debug/Release, and clicking manage/edit.
This is an old question but I happened to face a similar challenge. Well, for the benefit of someone who may experience the same here is how my problem was solved. I had a multi-project solution where some project depended on the source code from the other projects. Just before giving up and continue with the rebuild thing, I decided to check on the Build Dependencies=>Project Dependencies(Right-Click on the project). I found that the problematic code was from a Class Library that was not part of the dependencies(Unchecked). When I Included the project in the dependencies my problem vanished into thin air.
If you are referencing a .dll whose code is in another project you will need to build the project before the changes are reflected even if both projects are in same solution. sadly there is no running away from it.
Go to your configuration Manager and make sure build checkbox is selected for your project.
other thing you can try is:
Go to tools > Options>> A window will pop up> Under Project and Solutions > select Build and Run
Make sure Before building is set to Save all changes
(Copied from answer by amit dayama at https://stackoverflow.com/a/32820701/3195477)
I have faced the same problem because I have done some unsafe modifications upon the project names and have used find/replace upon the solution. Which resulted in a hidden exception in the android manifest file and exactly at the package name.
I avoid all types of headaches, I have created a new blank project with the desired name and namespaces and then moved the functional files, resource files and then modified static files like manifest and so on.
Never use unsafe method for project data configuration & modification