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.
Related
I developped a C# winform application to import rows from firebird db
when compile i have a message from vstudio that can't access to .exe file then an alert message from kaspersky to notice me from an trojan
pls help.
"VHO:Trojan-Ransom.MSIL.Convagent.gen" how is fix
OK, this setting fix. Visual Studio 2015 C# project.
Problem Solved By Changing The Value Of "Generate debug info" to "embedded"
Thanks.
It just happens sometimes. We faced these issues several times with different applications and different antiviruses. Some byte sequence in your program occasionally coincide with known virus ones, so antivirus gives a false-positive actuation. Change something in your program and recompile it - an issue will gone very likely.
Kaspersky it's using the heuristic scan, a technology which checks the code behind for the patterns. Some pieces of the code they are used in the malware programs and it gonna say that they are viruses. I remember that once I've created a service to insert some MySql data for wordpress, he said it's a virus, another time used a geojson to draw a map and it was saying that it's a virus when I've added a piece of code to draw for each city a dot.
I created a .Net Core App in Visual Studio then stripped out Bootstrap, JQuery, some validation scripts and brought it down to basics (3MB btw).
I tried Osman Hal's suggestion of creating an application without a manifest (under project properties) and that worked for a little while but I suspect the problem is there's not enough of a signature of (in my case) a Web Application to recognize as a valid executable.
That said the only true solution is is to exclude the Visual Studio directories from File Scanning.
Full steps to solve problem in visual studio 2022:
1- Go to Properties of project like this:
2- On Build section click on Advanced... like this:
3- Change Debugging information value to Embedded like this:
4- click OK and re-run your project.
Note: if this way not worked add exe file to white list of your
antivirus.
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.
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.
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.
I'm using TortiseSVN for my subversion client on a Windows Server 2008 box and I've got a folder with code checked out into it.
When I go to open the solution file that's under source control Visual Studio 2008 starts and before it can even finish loading the solution from what I can tell Visual Studio crashes. I'm trying to open a solution that has VB code in it. It gives no error messages or warnings. It's just gone.
I have checked the files and they all seem fine. The solution file seems fine when I look at it with a text editor.
This is also Visual Studio 2008 SP1 and I've got all the latest .NET service packs installed.
Has anyone else seen this before and know how to fix it?
Edit: I just did an SVN export to a new directory and it still crashes in the exported directory where there is no longer any SVN attached to it.
Additionally, it crashes EVERY time I try to open the project that came from SVN.
You should be looking at the solution file with an xml editor, at least then you will get some help for subtile flaw's in the formatting or something like that.
You can also submit feedback to Microsoft on the VIsual Studio Connect site, if the bug turns out to be real.
Some commonsense things todo however would be, goto your visual studio command prompt, start off with "devenv /ResetSettings", that often helps isolate any weirdo add-on or something lke that.
Also, try to build clean with msbuild or vcbuild, then build fully with either one (i.e. if vcbuild can not build your solution, use msbuild). That can help by laying out the symbols and such and maybe clear out some corrupted file or something.
You also may have .suo files from your subversion, those are binary files that do contain some settings, it's common for people to accidentially check them in, but they are usually better off being kept on a per-developer basis (not in the source tree). The /resetsettings will likely clear these out also, but you may want to make sure.
You can also double check the path's to all of the assemblies referenced, that your not going from a 32/64 bit host, and the CLR DLL's are in different path's now etc...
One last thing, if your really stuck, you can get a stack trace and debug the crash a bit ;), see where the fault is occuring and search that module online, your'll often find that somebody may have a specific solution.
Oh yeah, also, hooker's can be trickey. Don't trust them for a minute. Make sure you set tsvn's "only load in windows exlporer" option and configure it specifically for what folders on your system have local-svn working directories, this will greatly reduce the working set for their shell extension. On most any system, over time, one program or another (apple irw.exe or adobe pdf-preloader.exe sort's of ad-ware) will try to work it's way into your shell. You should try to make sure your dev box is rather clean from anything hook's, simular to what VladV was saying...
I had a similar problem and I fixed it and afterwards I wasn't quite sure how I managed it.
It basically involved going to the tools/options menu and setting the source control plugin to none. However, I obviously had to have had the solution open in Visual Studio if doing this was to fix the solution, but yet I thought the problem was I could not open the solution.
The only possible scenario would be if I was able to open the solution, but not open any of the projects inside it, hence able to change the source control settings immediately after opening the solution.
Does that make sense?
Try opening your solution and projects files in a text editor, and looking for anything strange.
I once heard of a similar problem: a solution contained SVN bindings created by AnkhSVN, but Visual Studio had no AnkhSVN installed, and failed to open the solution without giving any meaningful error information.