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#.
Related
I'm working on a Visual Studio solution using Visual Studio Professional 2017, the solution consists of four types of projects:
Several C++ projects
A C# project
Several C++ unit test projects
A C# unit test project
IntelliSense seems to be working for all, except for (at least) one of the C++ unit test projects, and it goes even further: for some tests inside that particular C++ unit test project, IntelliSense is working, but for some other, it isn't.
As mentioned in other Stackoverflow posts, I've already removed the *.cache files and there are no *.ncb files (so I can't remove them :-) ).
I also consulted the MSDN website, as proposed by Visual Studio:
Intellisense: 'No additional information available' (See 'Troubleshooting Intellisense in C++ Projects' for further help.)
I typed the mentioned sentence in MSDN search (learn.microsoft.com), and I got 229 results, which looked useless, and I got 0 results while searching for the exact phrase. :-(
Another approach : in my Visual Studio settings, I've maximised the messages, sent to the output window, I've rebuilt the whole solution, and afterwards I looked for the word IntelliSense in the output window. There was nothing. Then I typed something in order to launch IntelliSense, I verified the output window, but nothing was added.
In order to solve this problem, I need detailed information about IntelliSense itself:
I believe that IntelliSense is based on some files. Which ones?
I also believe that IntelliSense is keeping its own information in memory. Is this correct, is there a way to store this memory mapped information in files? If yes, which ones, and how can I force IntelliSense to refresh its information?
Whatever IntelliSense is doing (filling its information in memory, saving it in files, retrieving its information from those files, ...), what can I do in order to log those actions, so that I have an idea what might be going wrong?
In other words, does anybody have background information on the IntelliSense background task, which might explain what's going wrong, and how I can derive (from information in output window or other) what to do?
Thanks in advance
You can try resetting Visual Studio once
Devenv /ResetSettings
Sometimes Visual Studio has these gnawing bugs that just stresses you out for no reason.
Remove the hidden .vs folder from your solution. That would trigger index rebuilding.
Also you can try to install recent update for Visual Studio 2017, they seem to work actively on improving the indexing.
I want to compile a plugin for Notepad++ and used a .NET plugin to be able to write it in C# (VS17).
Without adding any code myself, the warning "Cannot find lib.exe in [...]\VC\bin" pops up.
I do get the .dll file but Npp throws two errors when adding the plugin to it:
Wrong version of Plugin
ANSI/Unicode Error
I am pretty sure that at least the version is correct, as I tried it with multiple Npp-versions, so i figured that maybe it's all about that warning.
Any suggestions?
"lib.exe" is part of the C/C++ toolset and is installed when support for the C/C++ language is selected in Visual Studio. Modify your Visual Studio to include C/C++ support. Running the set up program should allow the wanted suport to be selected and installed.
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.
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.
So on my computer I only have Visual Studio 2010 Express. I need to edit a Visual Studio 2008 project, however it needs to be kept in C# 3.5.
Before I open it in 2010 and accidentally upgrade it, will it be kept in 2008 or C#3.5 format?
I realize I wont be able to use .Net 2010 features, so thats no problem. I just want to make sure if I save my 2008 project using 2010 I will still be able to open it in 2008 and it will work fine.
The target framework of the project is independent of the solution format. That is, you can convert your project to Visual Studio 2010 and still target the 3.5 Framework. But, once it's converted to 2010, you will not be able to open it in 2008.
You cannot open a project in VS2010 without it being upgraded. The Framework version can be controlled independently, so you can still target 3.5.
The changes to the project/solution files to use 2010 (assuming you don't use any newer features) are fairly minimal, so there may be mileage in just not committing the project/solution files (you can probably achieve this by dropping an ignore file for your source control provider in your local folder, including adding the ignore file to itself, so that doesn't get committed).
If you're mostly editing code (and not often changing the projects in the solution, or files in the projects) you could also have two copies of the files, one for each version, until you can commit to 2010 everywhere (and with Express for free, you might be able to do this quickly?).
No, VS2010 will convert the VS2008 project file. After it is converted, VS2008 can no longer open it. There are ways to hack around this, the simple solution is to just use VS2010 consistently. Next best thing is to only check-in the source code changes. Next best thing is to give the 2010 project a different name and maintain them both, at least for now.
You'd be hard pressed to accidentally upgrade it. When you open a VS2008 project in VS2010, it automatically starts the upgrade wizard, and you have to decide whether to let it do the upgrade, including making a decision whether to let it take a backup before it does the upgrade.
You can't open a VS2008 project in VS2010 and work on it without upgrading it to VS2010 format first. And once you've allowed VS2010 to upgrade it, you won't be able to open it in VS2008 any more.
Careful though - don't confuse the version of the framework you want to target, with the version of VS that you're using.
You can target framework 3.5 with VS2010.
There are hacks that let you open VS2010-upgraded projects in VS2008, but it's not a great plan to go down that road (guess how I know).
When you are going to convert it with compatible to 2010 it will ask for the backup...
so... later you can retrieve your file back ...
I might be wrong but I'm almost sure that project files don't differ between 2008 and 2010 or at least they are compatible. Solution files are a different matter and old solutions do indeed need to be converted. Usually you have few solutions for 2008 and 2010 versions of VS, but they contain the same projects, so the projects don't need to be converted.
I was on a seminar where they took this (short of classic?) accident as a sample for versioning. They get a 2008 project from git and start it in vs 2010.
Did the upgrade process and then "ops, i can't revert the upgrade". They commited the vs2010 converted files to a branch in GIT. When they "came home again", merged the changes in project together with 2008 solution files.
This may not come in touch to you, but the sense is:
All files is intact but the solution/project files. So just keep them safe and you can continue use the 2008 version after done your editing in 2010.
Though, without any kind of manual handling of solution/project files - answer (on the question in your subject) is No!
In short, no. Once it's upgraded, it stays that way. There is no official way to downgrade it either. The main driver behind this fact is because of the compiler. Even if you stay in .NET Framework 3.5, you can still use C# 4.0 features (like optional / named parameters) since 2010 will always use the 4.0 compiler.
Imagine a situation where it stayed in a 2008 format but you used a C# 4.0 language feature. Since VS 2008 always uses the C# 3.0 compiler, whenever you open it in 2008, it will no longer compile. This is a good reason to avoid work-arounds that have been posted for downgrading - you get mixed compiler features that can break things pretty easily.