Develop Reference

VS2015 Illegal tables in compressed metadata stream

We're experimenting with upgrading from Visual Studio 2012 to 2015. The only error we ran into was
xyzRenamed.dll could not be opened -- Illegal tables in compressed
metadata stream.
We've been using this customer-supplied api dll in 2012 for a couple years without any trouble. Does anyone have any idea why 2015 would be unhappy with the dll while 2012 worked fine? Any way to avoid it?

It is likely that one of your DLL is obfuscated, specifically by a FOSS project called Confuser Ex. That project can be used in Visual Studio (as an addon) to obfuscate your code. When using that tool, you have a choice of protection layers. You can use some or all the layers. The protection that creates invalid metadata in the compiled DLL is the one that is creating this odd error.
You can deactivate the invalid metadata protection when generating the obfuscated dll in VS settings at VisualStudio->Tools->Settings->ConfuserEx.
In case you did not create the library, you need to investigate further, maybe use something else than Visual Studio 2015 to compile the project.

Remove
<protection id="invalid metadata" />
line from CRPROJ file.

It turned out that the customer had obfuscated their DLL by an invalid metadata tactic. Specifically, they were using ConfuserEx. This seems to work fine with VS2012, but VS2015 wasn't having it. Here is a bug report at ConfuserEx regarding the issue and it was basically deemed as expected behavior. https://github.com/yck1509/ConfuserEx/issues/313
We were able to get them to rebuild the DLL without this type of obfuscation and it worked fine.
I'm currently unaware of any way we could have modified our VS solution to make use of the obfuscated file. If you know of a way then please post it for others that aren't lucky enough to be able to acquire a non-obfuscated version of their dependency.

Could not load System.Net.Http.Primitives or one of its dependencies...gmail API

I am aware of the other question on this topic. Unfortunately, that question did not solve the problem.
My problem is outlined almost to the letter in this question. I am running the gmail-api in c# and the authenticator is complaining that it cannot find the System.Net.Http.Primitives file. I have followed all the steps of the answer--both steps 1 and 2.
Yet, the code still isn't finding the .Primitives version 4.2.29 (the current version of the primitives file). Is there another step to making sure the code can find the primitives file? I have updated all of the nuget packages in the solution to the latest versions. The primitives file is both present in the project and has been redirected to in the App.config file.

Somehow, installing the gmail api into only the .dll where it was called wasn't enough. Instead, I had to install it in all of the projects involved...in this case, the .dll and the unit testing project. That cleared up the problem.
Still have no idea why.

The source file is different from when the module was built error

I currently have one solution that references ten .dll files. Those .dll files in turn all reference a shared .dll file.
Today I started getting an error while debugging that stated, "The source file is different from when the module was built error.", immediately following a recompile of the shared .dll.
I tried all of the usual. I deleted bin and object folders. I recompiled. I closed all instances of Visual Studio and restarted after they were all closed. I restarted my machine. Nothing fixed seemed to fix it.

I'm guessing one of your 10 DLLs references a different copy of the shared DLL, and not the one you compiled.
Since you have all the sources, put all the projects in the same solution, and have the DLLs reference the shared DLL's project. This will solve your problem.

It has happened to me too. Once I fixed it by recompiling project-by-project from ground up (in the same order that VS does).
Another time this didn't help. I can't remember what I did then.
I believe it is a bug in VS.
I notice you are running VS2008. The problem might go away with an upgrade (the supposed bug might have been fixed). VS2010 is also nicer to work with than VS2008 so it could be areason of its own to stay current. Why not download an evaluation VS11 and try it there.
Move all projects to one solution, reference them in a simple and correct way. Compile. Now you have the right DLLs everywhere and can go back to your more diverse solution(s).
You can also try to use MSBuild. It is easy since you already have the projects in VS. Once it is build by MSBuild (which VS uses itself) it should probably compile in VS again.
Finally you can try to build with nAnt. Once it compiles you can probably compile in VS again.
Good luck. I've been there. It sucks.

I suppose you referencing in your project directly to some DLL, and not a project. Which means if you even cleanup and rebuild, the same dll will be used like a reference.
Very often this is a problem, so I suggesting you check your references.

[edit] Assumed this was asp.net, disregard. [/edit]
Have you deleted everything your temporary .NET folders?
Either in:
C:\Windows\Microsoft.NET\Framework[Your Version]\Temporary ASP.NET Files
or
C:\Windows\Microsoft.NET\Framework64[Your Version]\Temporary ASP.NET Files

When comparing last-modified dates of the shared .dll across output folders of all of the solutions with the file that was stored in the output folder of the primary solution, I noticed that they were not the same as the file that I had just built.
This didn't make sense to me, so I simply copied the new files into the output folder. This did NOT solve the problem. On subsequent builds, the old version was again placed into the output folder, immediately causing the error while debugging...
During compilation, an older version was being pulled along with one of the other referenced .dlls. There is obviously some sort of check that is made with the names of files pulled in so that only 1 file is used, but no check is made for latest version number.
I was able to actually solve the problem by creating a reference to the shared .dll from the primary solution. Direct references are obviously (or perhaps hopefully) pulled in before files that are referenced by references (and are already copied into the same output folder as those referenced .dlls), so the latest file was successfully pulled in first.
If clarity is needed, let me know!

I rarely respond to posts since I am generally too busy, but I just spent a ton of time on this same exact problem. I am running VS 2008 in Windows 7. I had set the my Visual Studio to run in XP Compatibility Mode to fix some issues I had with a different project and forgot to reset it to NOT run in compatibility mode.
Once I removed the Run In compatibility MODE (In Windows Explorer on the DevEnv.exe) my problem with the source being out of sync with the debug information went away.
Hopefully this might help someone in the future with the same problem.

Undefined Web.config error in VS 2008

I'm working on a web app using VS 2008, .Net 3.5 and C#. Most of the projects in the solution are either classic asp.net pages with some MVC 1 in the mix, the rest is shared libraries. The solution is one that is some 5 years old and has gone through a variety of developers working on it and clearly has some performance and architectural issues.
Previously, I've been working on the project using VS 2008 on a Win XP machine, but have just transitioned over to a new box using Win 7 Ultimate. To do so, I've installed VS 2008, asp.net 3.5. To support future work on the solution I've also installed VS 2010 and asp.net 4.0.
Opening the solution on the new box with VS 2008 works fine, and it builds without error. However, when I attempt to run it with the debugger, I get the following message:
"There is an error in web.config. Please correct before proceeding. (You might rename the current web.config and add a new one.)"
I think it's clear that there is some sort of environmental issue regarding web.config on the new machine, but the error message is not "helpful". Adding a new web.config is not an option as the existing one is quite long and involved (too much to post here).
I'm hoping someone has a suggestion or two about where I might look for missing elements or changed configurations that might produce such an error message. Lacking that, I'll revisit this post and provide the web.config in the hope that will elicit further help.

So I don't know if you ever found an answer to this, but I ran into it in VS2013 today. Oddly, it would work if I had the web.config open in an editor window.
For others who may see this error I was able to clear it in VS2013 by deleting the \bin and \obj directories.
After that, it worked fine again...

To maybe give you a better idea of what the web.config problem is, I would follow the suggestion of renaming the current one and adding a new one. You can use a diff tool (e.g. WinMerge) to find out what the differences are between your existing config file and the "clean-slate" new one.
You can copy the non-issue sections from the old one to the new one, like the connection strings and the application settings, forms authentication modes, etc. You might have something wrong with the compiler section or something a little more specific to the .NET framework.
Did you convert the project at all from targeting .NET 2.0 to .NET 3.5? There's a big web.config section that gets added to 3.5 projects that wasn't required for 2.0 projects regarding the compiler, as it uses a separate compiler for .aspx inline-code than was used for 2.0.

iis 7.5 (on windows 7) is a pretty different animal than iis 6 (on windows xp). there are some configuration incompatibilities. one thing that comes to mind is a little different schema for the attributes on the elements for http handlers and modules. there are other things that are different. usually on the error page, it will tell you what it doesn't like. i imagine it was there and maybe you didn't notice it. or maybe you were hitting the page remotely and it didn't have all the detail. i suggest using a browser on the local machine and take a closer look - pretty sure it will tell you what is making it puke.

I ran into this ambiguous error for the first time today in VS2019. I had added a new Entity Model (.edmx) which required adding a new connection string to a separate project's web.config. After adding it, I immediately started getting the error on startup. I noticed there were several config transforms for the various environments. After adding the missing transformed connection strings to each of them that error has gone away.

Visual Studio 2010 suddenly can't see namespace?

My C# WinForms solution has two projects.
A DLL which is the main project I'm working on, and an executable WinForms I call "Sandbox" so that I can compile/run/debug the DLL easily in one go.
I'm working in .Net 4.0 for both projects.
Everything was working fine until I added some seemingly innocent code, and a reference to System.Web in the DLL.
Now my Sandbox project can't see the namespace of the DLL project. I didn't change anything which I believe should have affected this.
If I delete the project reference to the DLL from the Sandbox references and re-add it, then the red underlines all disappear and the colour coding comes back for all my classes etc; but as as soon as I try to build the solution, the whole thing falls apart again.
When I right-click the DLL project in the Sandbox's references and view in object browser, I can see the namespace and all the stuff in there.
I have a feeling this might be some sort of bug?
Is this some sort of VS2010 bug? I had this same issue a few months ago and I could only fix it at the time by making a whole new project and re-importing my files. This time, however, I have a bajillion files and will only do that as a last resort!
Edit:
After panickedly going through and undoing all my changes, trying to find what caused the problems, it seems to be this line:
string url = "http://maps.google.com?q=" + HttpUtility.UrlEncode(address);
If I comment out this line, then I get no namespace errors and the project builds fine. I can't see anything wrong with this line though.

I'm ready to declare this a bug in VS2010, this has bitten way too many programmers already. The fix is easy: Project + Properties, Application tab, change Target Framework to ".NET Framework 4" instead of the Client Profile that is selected by default.
System.Web is not included in the client profile. Having this option in the first place is quite silly, the client profile is only 15% smaller than the full version of .NET 4.0. Having it selected by default is even sillier. But I digress.
UPDATE: mercifully this all got fixed in VS2012. Which no longer makes the client profile the default for a new project. And the client profile got retired completely in .NET 4.5, good riddance.

Check to make sure that both projects are using the non-client profile for their target framework (go to each project's properties to do this).

One possibility is that the target .NET Framework version of the class library is higher than that of the project.
I faced this problem, and I solved it by closing visual studio, reopening visual studio, cleaning and rebuilding the solution. This worked for me. On some other posts, I have read the replies and most of users solved the problem by following this way.

Try building only the project with the Sandbox dll first independently.
Then point your executable project to the required dll and ensure copy local is set to true. in reference settings.
Tthen build the executable project.

Changing the target framework from the ".NET Framweork 4 Client Profile" to ".NET Framework 4" worked for me with a similar problem. I agree that the client profile doesn't seem to have much of an advantage to using it. I seem to get nailed with weird errors that I hunt for until I remember that Visual Studio defaults to the client profile. I guess the moral of the story when getting an error is: if "Rebuild Solution" doesn't work, check the Target framework...

If you tried already doing the Framework change, and still not worked, I hope this works for you (as it did for me): Simply add the necessary references from within your projects. Very obvious but I was doing it wrong until I found what was the issue.

I just had this issue and it turned out to be I had multiple namespaces being used that had the same object name (i.e. business objects had the same names as mvc models);
Fully qualifying the names fixed the issue for me.