I have a project with a .txt file in a folder. The .txt file is set to Embedded Resource.
I use this code to read it:
var assembly = Assembly.GetExecutingAssembly();
var manifestResources = assembly.GetManifestResourceNames();
string s = manifestResources.Single(c => c.EndsWith("Cats.txt"));
Which works great.
However I updated Cats.txt and noticed my project didn't update.
I deleted Cats.txt and found that it is still working fine and reading the file.
I tried cleaning my solution, rebuilding, and iisreset, but it seems to insist the file is still there in the assembly despite me removing it.
Any ideas?
Actually, the problem is solved by Cleaning the solution first, and then Building it again. I did not have to quit Visual Studio to update my embedded resource.
Rebuild solution (or startup project) updates embedded resources.
Okay so I fixed this by restarting visual studio. I have no idea how that affected it.
When I inspected the properties of 'assembly', the CodeBase attribute was pointing to an older copy of the DLL in a completely different folder, that was somewhere else on my hard disk, that I had open in another Visual Studio window.
I have no idea what underlying mechanism caused this to happen, I definitely had the correct version of the solution open and I was debugging it.
Closing the solution and opening it again fixed it. Chalk this one up to bizarro caching behaviour or something.
I had the same problem, cleaning building and many other things didn't work. I had to modify the resource designer. After that, the resources were rebuil correctly
Related
My Visual Studio is not showing a lot of the available classes in the IntelliSense auto-complete. For example, a project I'm working on has a reference to the Microsoft.Xna.Framework namespace, yet even after adding the using statement using Microsoft.Xna.Framework in a file, IntelliSense is unable to recognize classes like Texture2D and Rectangle. I can still type them in, however, without getting a compiler error. Any idea what's happening?
The IntelliSense detects standard libraries like System.Diagnostics but not any external ones.
It is not a NameSpace conflict issue because classes within the current namespace are also missing from the IntelliSense.
I have tried:
Restarting Visual Studio (With and without closing tabs)
Deleting the contents of %LocalAppData%\Microsoft\VisualStudio\14.0\ComponentCacheModel folder
Resetting import and export settings
What worked for me is unloading and reloading the project
If unloading/reloading the project doesn't work, try deleting the .suo file found in the SolutionName/.vs/ folder. The .vs folder is an auto-created, hidden folder so you will have to show hidden folders in order to see it.
I am using ReSharper. What worked for me:
Unload project.
ReSharper > Options > Environment > General > Clear caches
Close solution.
Exit Visual Studio.
Restart Visual Studio.
Reload project.
Do you have ReSharper or any other plugins installed? There sounds like a similar issue/solution here. It may be third-party plugins at play depending on what add-ons you have.
Try saving and reloading the files.
I don't know why it happens, but it happens to my work laptop occasionally, typically reopening the source file resolves it.
OK so probably not the best solution but it works. I reinstalled Visual Studio and the problem was fixed. Also, it hasn't shown up since (this happened about 3 months ago).
another dumb solution))) Determine which classes/namespaces are not showing up. Then go to that project where they are. In that project pick any .cs file copy its contents, then delete that file and create again))
Click on the class not showing and Change Build Action -> to Compile
it happens sometimes when you add class as content or other resources
I don't know exactly how, but on a certain moment we ruined our complete visual studio solution. It wouldn't build anymore, nor clean, nor find any reference.
Afters hours of searching and trying to fix everything we got to the point that everything was building and running again.
However.. every time we open our solution we will get the message “Projects have recently been added to this solution. Do you want to get them from source control?”.
This is probably cause by trying to fix one thing and breaking something else.
How do we get rid of this message?
Thanks to some research and trying some various options this is what solved it in our case.
1. Unbinding the solution file from TFS
Unbind the solution file (.sln) from TFS. We did this (in visual studio of course) by going to the menu File => Source Control => Change Source Control.
2. Cleaning the solution file by deleting globalsection
We had to clean the solution file (.sln) by opening it in a text editor (we used notepad++). We removed all occurences of GlobalSection(TeamFoundationVersionControl) = preSolution. Including the mentioned starting tag and the ending tag EndGlobalSection.
3. Bind the solution file to TFS again
Finally we binded the solution file (.sln) to TFS again. We did this (in visual studio of course) by going to the menu File => Source Control => Change Source Control
Thanks to http://www.nivisec.com/2008/09/vsts-projects-have-recently-been-added.html who pointed us in the right direction after some hours of research.
I had this same error. Turned out to be a project that was deleted from source control but still referenced in the .sln file. Was difficult to spot as we had >100 projects in the solution.
Had a same problem, project was removed from solution but for some reason SccNumberOfProjects under GlobalSection(TeamFoundationVersionControl) = preSolution in solution file was at wrong count - there was 56 projects in solution and reported number was 57.
Had a similar issue to this. There was a project file which was referenced and had been renamed. The .sln was not aware of the project file name change. The fix was the checkout the .sln file, and update the reference to the project file.
This method is allot easier and less time consuming:
Close the solution.
Go the the folder which contains the solution file.
Delete the hidden ".vs" folder.
It won't do any harm but if you're afraid you can always rename the folder instead of deleting it.
I've searched everywhere and I can't seem to find anyone with the same problem (although I'm sure people have made the same mistake in the past)...I accidentally deleted the contents of my Debug and Release folders. Now I am getting file not found errors. As a background, it's a Windows Forms Application in C#, and I'm running Visual Studio 10.
Here's the errors:
Unable to read manifest 'bin\Debug\projectName.vshost.exe.manifest'
Could not find file [pathName]\projectName.vshost.exe.manifest.
Before I was missing the manifest, I was getting an error that it could not find the other contents of the folder (the exe, the pdb, etc.), error MSB3113 (link)
Things I've tried (and some of them were far-fetched, I know):
I tried renaming bogus files for all the missing files
I tried to find the deleted files, but can't
I tried deleting all the contents of the Debug/Release folders and doing a clean build
I tried deleting the Debug/Release directories
Let me know if you can think of anything I could try out. My issue seems to be vaguely similar to this one.
Here's how I ended up solving the problem - turns out I included my bin and obj directories in my project. For anyone experiencing the same problem, simply right click and "Exclude From Project." After doing this, clean and rebuild your project, and you should be good to go.
In my case the file app.manifest was checked-out. This file is located in my Winforms project under Properties folder. I selected this file from Pending Changes window and did "undo pending checkout". After that the build succeeded. This happened in Visual Studio 2008.
Worked for me: Properties => Build => Generate serialization assembly => change from Auto to Off
We have a SQL file that's an embedded resource in our solution. When the sql file changes, and we click debug, the solution doesn't rebuild the project with the embedded resource if no actual C# code has changed.
I've had this issue with other solutions as long as I can remember, and I personally know to do Build Solution to make sure it gets built...but this has become an issue for a number of new developers who can't remember to do this and get confused when their changes to the SQL file aren't reflected at debug time...so I was wondering if anyone knows an easy fix.
The easiest fix is to "rebuild" instead of "build". Other people will "clean" and then "build" to be 100% sure.
Embedded Resources are not updated in the debugging DLLs unless the output DLL is truncated, which can only be guaranteed to occur with rebuild and clean.
Unfortunately, a clean and rebuild does not seem to always work for Resource files. My issue was with a string resource file, and how I fixed was as follows in VS2016:
Close .resx and .Designer.cs if they are open in the IDE
Delete .Designer.cs class (right-click, delete in solution explorer)
Double click .resx file in solution explorer to open
If required, change 'Access Modifier' from 'Public' to 'No Code Generation', and save
Change 'Access Modifier' from 'No Code Generation' to 'Public', and save
=> the .Designer.cs code should then update
I ran into the same issue with VS2017.
This is what worked for me:
Open the .resx file. Make sure you are in the Resource editor, do not use an XML editor since sometimes changes done there will not trigger the generation of Designer.cs
Make sure Designer.cs is not open.
Do a small change, save
Undo the change, save
After converting my project into VS2010, everything looks fine ( gui, etc..), but i can't build it because of this error. When i double click on the error it leads me to the resource file but doesn't show me where the problem is.
Object reference not set to an instance of an object. -Resources.resx
My project works fine on VS2008, was built on .net 2.0 , does any one know how to fix this ?
Thanks
In my case this happened after copying a form from one project to another.
It seems VS lost the reference to one of the local resource images.
Re-adding the image fixed the issue.
Well, something got messed up, but without bashing your head around it too much:
Use row headers to select all rows in the resources file.
Copy the selected content to Notepad.
Delete the resources file in Visual Studio.
Create a new resources file with the exact name.
Copy/paste the content from Notepad back to the resources file.
That should do the trick. This only works with string resources. If you have other types of resources, I am afraid that simple copy/paste will not be as simple. Either way, I think that recreating the resources file is the easiest solution.
Principle: "Don't know, don't care. Just make it work" :)
I had the same issue when copying a windows form from one project to another. After some research I found that it was due to the version of the .Net Framework.
Make sure that the project where the resx file sits is the correct version. If you copied it from Project A to Project B, make sure that the .Net version of Project B is the SAME as Project A.
See http://www.codeease.com/object-reference-not-set-to-an-instance-of-an-object-in-resx-resource-file.html
Hope it helps you
I was moving project from XP 32 bit machine to 64 bit Win 7 machine. The project was Framework 2.0
In my case easy fix. In the resx file change all the Version=4.0.0.0 to Version=2.0.0.0
I got this problem when I worked from a network resource, even though I had write/read access too it. When I moved the files to a local folder, it started to work.
Something that often worked for me was modifying the resource files like this:
1. Go to the resource in design view and copy all the string entries.
2. Delete all the entries from the design view and save.
3. Go to the code view and remove the data entries/nodes (they were not removed on my machine, even though I removed them from the design view).
4. Rebuild the project.
5. Go to the design view and paste the entries you previously copied and save.
6. Rebuild and it should work.
Unfortunately my answer won't really help you, but is consistent with the ones above.
The errors (seemingly) spontaneously went away.
Here's some other info that might help... (I had two of these errors)
My scenario was I initially developed on VSexpress2010, 32bit XP. Recently upgraded to Win7 64bit. (clean install, bring all my code back in now...)
It seems this error is usually thrown by trying to reference some null object (I've lost the reference). So I tried this even though my code was working previously... No luck, but after I removed the new 'fix' code, the error for that object was gone. Just played around with the file.
I came across this page too http://www.codeease.com/object-reference-not-set-to-an-instance-of-an-object-in-resx-resource-file.html .
I searched my remaining resx, but had "Version=2.0.0.0". Anyway, after the search, I debugged and it's gone.
Short answer: It's like magnets, how the F##k do they work? Just play around with your file, and keep debugging... hopefully eventually it'll work.
recreate the resource file copy/pasting (assuming it's text)
make some edits in your file. save. remove the edits. save again.
search around the file.
chances are it's not your code, and some mystery VSbug.
Good luck.
+1 #Boris's answer because it really is a case of
"Don't know, don't care. Just make it work" :)
In my case I convert my project from framwork 4.0 to 2.0 and also copy a Form .cs file and Designer file after that I am getting same error.
But as I delete the .resx
The error gone.
Please try to delete .resx may it help you!
Problem occurred after an unspecified crash of VS-2010 which apparently corrupted the project.
The RESX file was not changed at all (as determined from a backup copy of the project). There seemed to be invalid references in the VSPROJ file. I was not sure how to correct them by direct edits.
As per "Rohan" in 2012. I removed a background image from a form and the problem went away.
In my case, the problem arose when I copied the project to a new location. The problem was solved when I copied all the resx files from the original project, after verifying that the project compiled fine, and pasting them into the folder of the project that had issues. Clearly, a corruption issue that seems to be common when copying projects to new locations.