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.
Related
Returning to Visual studio after a few years away and really stuck with this one.
I inherited an Excel addin project for calling rest services that needs a few tweaks. No problem with code. It uses the NetOffice component which seems quite useful for handling COM interop.
It was on a windows 8 machine 32 bit visual studio 2013 community. I am on windows 10 64 bit Visual studio 2015 community fresh install.
I tried copying all the project files to my PC, open solution file and go:
Just once, the first time, it ran and paused on my breakpoint, but never after that. it still runs on other persons pC- not too big a surprise.
It even complained after the build that did not have permission to unregister the dll from (the old PC)
A text search of the project for the old PC name found nothing.
Edited all references and paths in properties file. Opened solution and project files in notepad and satisfied that nothing now points to previous machine.
It builds again but fails to stop on breakpoints. Then it complains that it can't find the login properties in the login file on (you guessed- the old PC)
I tried building a new project from existing files. That seemed to go well, but it failed to add references and I can't even find the references via add reference dialogue, Most peculiar it complains that a sub namespace of system does not exist. I tried different target .net frameworks without any luck and gave up on this approach.
I suspect part of the problem might be connected to my using 2015 community edition and the template might not be installed that was originally used ti build it.I used a class library when I attempted to build a new project manually.
Is there a safe procedure for inheriting a project like this and getting it set up cleanly on a new PC?
I realise this is a fairly dumb newbie question, but I am really stuck now.
Thanks in advance
If you will use same version of Visual Studio on destination PC than you can just copy/paste your project to the destination PC... but as chandler mentioned the best way to to that is to use some kind of source control like GIT or TFS (Team Foundation Server), with source control method it will be less painful for you to accomplish that movement of projects.
And if you choose the Team Foundation Server you have unlimited number of free repositories as long you are a small team up to five members.
Please see pricing models and additional information here: Visual Studio Team Services Pricing
I have a file called Asembly-CSharp.dll i want to edit in C#. I decompile it with .NET reflector's FileGenerator (also tried file disassembler and dotPeek) plugin, thus creating a visual studio project, i open it in visual studio, but it fails to build, i didn't change anything, yet i get lots of errors (like unexpected characters etc), the dll refers to lots of other dlls but even if i put all of them in one solution it fails. Why does it fail if i didn't change anything in the source code (.NET framewrok version is the same as it was before decompilation). Any help appreciated.
I tried both visual studio 2012 and 2013 (win7 but i know that shouldn't be the problem)
I'm not professional, forgive me if i made some silly mistake.
Reverse engineering needs a bit of effort. Nothing comes for free. You need to manually fix those errors.
Mostly these errors occur because either Reflector decompiles the code with compiler-generated variable names that are valid in IL but not in C#, or because that particular assembly was written in some other language that supports features that cannot be directly translated to C#.
ide: vs 2012 v11.0.60610.01 update 3
project: web site, mix of vb and c#
problem: vb navigates to definition, c# navigates to metadata
complaint: complete pain in the ass when managing a 30k code-line project.
solution: you be the first to figure this out, it's beyond my level of patience.
i find metadata to be 110% useless.
is there ANY way to get c# to navigate to the actual definition like vb does?
thanks
If it's navigating to the metadata, rather than the definition, it probably has to do with how your assemblies were added. If you add a reference as a DLL, it will always show metadata, even if that project is included in your solution; you have to add a reference by project to have access to the source.
"i find metadata to be 110% useless. is there ANY way to get c# to navigate to the actual definition like vb does?"
Resharper's go to definition/go to implementation options work exactly as you'd expect - worth trying it to see if it fixes your issue.
This question might be of help if you choose not to try resharper
I realize this is an old thread, but it seemed to be one of the few that focused on the role of mixed languages (C# and VB.NET) as a contributing factor to this.
I ran a few tests across VS.NET 2010, 2012, 2013, and 2015. My empirical results (not validated by any official Microsoft documentation) is that all 4 support Find All References of VB.NET members consumed by C# (albeit, split into apparently separate result groups), as long as project references were added. However, VS.NET 2010, 2012 and 2013 end up in the "from metadata" view for Go To Definition from the C# code to a VB.NET member. Where as VS.NET 2015 appears to have this cross-language Go To Definition navigation working correctly.
I also confirmed that using Resharper's support for External Sources does allow Go To Definition to work under VS.NET 2012, and that almost motivated me to purchase licenses for Resharper for our current project that has mixed C# and VB.NET projects, but now my plan is just to expedite adopting VS.NET 2015.
I try to compile with VS 2008 old C# Service project based on WSE where DIME attachments are used:
The compiler does not find:
using Microsoft.Web.Services.Dime
I just installed WSE 3.0. Even that does not help to find Microsoft.Web.
What is the replacement for DimeAttachment class?
thanks Arman
EDIT
Well the answer what I marked as a answer is not really related to my problem but the comments were putting me in to right way.
I just learn from http://msdn.microsoft.com/en-us/library/aa529283.aspx that WSE3 handles attachments differ and I just migrated few lines to WSE3 and code is running.
Is the required DLL physically present on your disk? If so, remove the reference and re-add it by selecting the DLL that you know is there. If that works, sounds like the original referenced version just could not be located and your ReferencePath needs fixing.
I´m working on a project, in Visual Studio 2008, which DLL currently surpasses 20 MB. Is there a way to profile that DLL, searching the main contributors to this size?
I suspect that breaking it in smaller projects inside the solution would help, but I'm looking for a faster solution (although not better, I'm afraid).
As a sidenote, we are getting 'unexpected error writing metadata' error, that we think it's related to the DLL size. However, when restarting Visual Studio 2008, the error vanishes. Until it appears later again, after a few rebuilds. The disk space is not a problem.
Yowser! Have you perchance got some huge resx files (or other embedded content) that are getting embedded in the dll? Perhaps treat those as external content? I'd start by looking at the files in the project tree... that 20Mb has to come from somewhere obvious - large graphics, etc.
PE Explorer will show you the contents.
This may also help?
Update:
Dependency Walker may also help here. You can run it in "Profile Mode" which works by executing your application and watching it to see what it loads.
Microsoft.SharePoint.dll is 9Mb. Even for a complex product like SharePoint, DLLs are separated into separate projects.
If you have a large project and that nothing is coming from the resources, might I suggest splitting your project into different assemblies?
I saw the exact error you had but on a VS2003 environment (which Microsoft showed on support.microsoft.com). However, since you are in VS2008, it might also be due to a disk space issue.
Did you verify that all the disks used by Visual Studio are not full/almost full?
Oops!
Found a bunch (50+) of huge report templates generated using Crystal Reports, each one around 1MB.
All we had to do was excluding them from project.