I'm trying to re-jig the layout of a very large solution which has become impossibly hard (and s l o w) to work with. My plan is to create a number of solutions containing related projects, and then use binary references where necessary to link to libraries produced by the other solutions.
The thing we rely on to make this usable is Resharper's Navigate to External Sources functionality, so we can easily browse the source of the projects we are referencing from other solutions. Quite why VS can't do this out of the box is beyond me.
This is all working very nicely for classes with implementation. However, for C# interfaces and classes containing only auto-implemented properties, Resharper isn't able to browse to the sources, and falls back to cruddy metadata viewer.
I used srctool.exe, which comes with the Symbol Server tools in MS Debugging Tools For Windows, to browse the sources listed in the .pdb file, and it's clear that the sources for these interfaces and empty(ish) classes are not referenced in the pdb file. If I switch the auto-implemented properties to those with backing fields, then the source link appears in the pdb.
I'm guessing the sources are excluded because there are no places you could set breakpoints on interfaces and auto-implemented properties.
I'm wondering, though, if there is some exotic compiler option or workaround we can employ to force the PDB file to include references to the source of C# interfaces.
Thanks,
Mark
The question doesn't have enough detail. Shooting off the hip, I'd guess that you tackled the problems with the slow massive solution by converting project references to assembly references. And used the Release build of those projects as the reference.
And yes, that stumps any tool that tries to find source code files from the PDB. The release build of a .NET project uses a stripped version of the PDB, all the source code file and line number info has been removed from it. That's a pretty normal thing to do with real release builds. Release built code normally is optimized. That causes code to be re-ordered, no longer matching the logical position of the code in the source file. Any info you get from the source+line PDB info now tends to get between harmful and useless, you start looking in the wrong place for a problem.
That is however not a concern for IDE tooling or while debugging your app. The optimizer is automatically disabled in a case like this. Actually a configuration item in VS: Tools + Options, Debugging, General, "Suppress JIT optimization on module load" option. Turned on by default.
Clearly any tooling that uses the PDB is going to catatonic when they don't have a chance to find source files. The fix is to go back to the original project, select the Release configuration again and change a setting: Project + Properties, Build tab, scroll down, Advanced button. Change the "Debug info" combo from "pdb-only" to "full". Rebuild the project.
Should fix your problem. Also revives the debugger, you can step into the source code again.
Don't move files around too much btw, you might stump the chumps again. At least keep the PDB with the DLL in the same directory. If the source code is no longer present in the same directory but you checked it out again in another one then you have to tell the IDE about it. Right-click the solution, Properties, Debug Source Files setting.
Related
I wrote a windows application using C# .Net 2.0 and i want to do something which hide the source code, so when any one use refactor tool can't see the source code.
I used dotfuscator but it just changed the function names but not all the source code.
UPDATE:
I want to hide the source code, not because of hiding the key, but to hide how the code is working.
Thanks,
IL is by definition very expressive in terms of what remains in the body; you'll just have to either:
find a better (read: more expensive) obfuscator
keep the key source under your control (for example, via a web-service, so key logic is never at the client).
Well, the source code is yours and unless you explicitly provide it, youll perobably only be providing compiled binaries.
Now, these compiled binaries are IL code. To prevent someone "decompiling" and reverse engineering your IL code back to source code, you'll need to obfuscate the IL code. This is done with a code obfuscator. There are many in the marketplace.
You've already done this with dotfuscator, however, you say that it only changed the function names, not all the source code. It sounds like you're using the dotfuscator edition that comes with Visual Studio. This is effectively the "community edition" and only contains a subset of the functionality of the "professional edition". Please see this link for a comparison matrix of the features of the community edition and the professional edition.
If you want more obfuscation of your code (specifically to protect against people using tools such as Reflector), you'll need the professional edition of Dotfuscator, or another code obfuscator product that contains similar functionality.
As soon as people get a hand on your binaries they can reverse-engineer it. It’s easier with languages that are compiled to bytecode (C# and Java) and it’s harder with languages that are compiled to CPU-specific binaries but it’s always possible. Face it.
Try SmartAssembly
http://www.smartassembly.com/index.aspx
There are limits to the lengths obfuscation software can go to to hide the contents of methods, fundamentally changing the internals without affecting the correctness (and certainly performance) is extremely hard.
It is notable that code with many small methods tends to become far harder to understand once obfuscated, especially when techniques for sharing names between methods that would appear to collide to the eye but not to the runtime are employed.
Some obfuscators allow the generation of constructs which are not representable in any of the target languages, the set of all operations allowable in CIL for example is way more than that expressible through c# or even C++/CLI. However this often requires an explicit setting to enable (since it can cause problems). This can cause decompilers to fail, but some will just do their best and work around it (perhaps inlining the il it cannot handle).
If you distribute the pdb's with the app then even more can inferred due to the additional symbols.
Just symbol renaming is not enough of a hindrance to reverse-engineering your app. You also need control flow obfuscation, string encryption, resource protection, meta data reduction, anti-reflector defenses, etc, etc. Try Crypto Obfuscator which supports all this and more.
Create a setup project for your application and install the setup on your friends computer like a software. There are 5 steps to creating the setup project using microsoft visual studio.
Step 1: Create a Sample .Net Project. I have named this project as "TestProject" after that build your project in release mode.
Step 2: Add New Project using right click on your solution and select setup project and give the name this as "TestSetup".
Step 3: Right click on setup project and Add primary Output and select your project displayed.
Step 4: Right Click the setup project and select View-> File System -> Application Folder. Now copy what you want to be in installation folder.
Step 5: Now go to our project folder and open the release folder you can get the setup.exe file here. Double click on the "TestSetup" file and install your project to your and other computer.
0) How to debug unityContainer?
Im working on a legacy project on the firm, and all projects are loaded using dependency injection using unityContainer. I need to make improvements on the presentation layer, but I cannot debug the code, only the main project, witch loaded all modules.
The code used for loading modules(projects):
unityContainer.RegisterType("FrontEndModule", new InjectionMember[0]);
On the module, i register all project types like this:
unityContainer.RegisterType< IAboutPage, AboutPage>();
And then I run the main form:
Application.Run((Form) unityContainer.Resolve< IMainPage >() );
1) So there is any way to debug the code of the loaded projects?
2) Do I need to make any change to be able to debug?
I've tried to run the form directly, but then there is a lot of injections needed to run. Maybe I would be able to use another IoC framework that permit me to debug the code of loaded projects.
Thanks.
There is nothing special about Unity when you debug code.
To be able to steps through the code you need
PDB files matching to DLLs that you are using (often it means "rebuild locally" unless PDB published along with DLLs)
source code, preferably matching the version of the source used to build DLLs (VS will allow to use mismatched sources, but you'll likely get very poor experience when stepping through does not match what actually happening since line numbers in PDB no longer align with actual text source)
you may need to disable "Tools->Options->Debug->My code only" setting to allow stepping through/breakpoints in code outside of solution (that's depending on VS mood :) )
If you can't get PDBs you still can see exceptions and call-stacks (as this information is part of DLL metainfo).
Switching to another DI framework will not have any impact on that.
In my application i am using the third party dll and i dont have any soruce code avialable.
Now i am getting the exception in Windows7 OS, so i would like to debug and kwow what is the exact reason.
Reflector will not help me in this case as its a unmanaged dll. And decompiler is giving error on passing this dll(Extraction of source code).
To debug in visual studio, it expects the PDB file and .pdb can be generated only from source code.
In the debug section i slected "Enable Native code debugging option" and in security section i selected the option as paritially trusted application to get rid of the exception.
I am not able to conclude, what could be the problem and dont have any idea apart from above, how to resolve?
On my knowlege we can not debug unmanaged dll, if we dont have source code available.
Can any one please suggest, if we have any techniques around that.
My thought process: If i can get runtime information on which API its failing, i could opt for alternative API and resolve the problem.
Thanks in advance.
Regards,
Siva.
Of course you can debug it. You can step through assembly code just fine and check the state of registers, etc.
It seems that you really want to debug by inspecting and executing the original source code. This is obviously impossible without the source code, as it is in general not possible to reverse engineer the source code from optimized native executable (it is possible to reverse engineer functionally equivalent code, but this can differ heavily from the original source). Native dll usually doesn't contain names of the symbols (classes, functions, members, etc) except for the exported ones, so it is not possible to create e.g. a friendly stack trace with method names.
Besides that, even if you had source code, it would be useless without symbol file (.pdb), as pdb contains data about mapping between original source code and compiled instructions, as well as other information (symbol names, optimization info, etc).
However, it is not that hard to debug using assembly code if you have a pdb file but not the source code (ok, it is not that easy, either :). These 2 articles (http://www.microsoft.com/msj/0298/hood0298.aspx and http://www.microsoft.com/msj/0698/hood0698.aspx) have enough info to debug most of the usual situations where you might need that.
I've got a bunch of .dll assemblies, such as HtmlAgilityPack and MoreLinq. Where am I supposed to put these files? I usually toss them somewhere in my Projects folder, but then I'm always digging around for them. Is there a standard place to put them?
There's no standard place to put them, but make sure you:
Put them in one place
Include them in source control.
I put all my required dll's in a top level directory in my solution called "Dependencies", parallel to the project folders. I have them in source control such that when new developers check out the solution, it all compiles and works right off. It's the only way to go.
I include only the .dll files absolutely needed. This keeps it light, which is good, but then when I find some other part of MVC Contrib or whatever that I need, I have to go find the unzipped directory, which might not even be on my computer! Others put entire library directories (readme.txt and all) as part of their source control linked to the solution. This ensures you and future developers will have everything they need, but adds a little dead weight. Either is a good strategy.
Having a "Lib" folder at the same level as source projects is a common way.
To be honest, it's not the dependencies my projects have that I find hard to manage, it's the dependencies the dependencies have. I'd just like to mention NHibernate, Castle Windsor and the various Castle Windsor Facilities in particular. Getting all of those to play together on my last project cost me a lot of time.
For open source projects, I also like to have the source code handy because sometimes its useful to debug into the source code. (And sometimes because the documentation is so poor, you have to read the source code to find out how it works). I've seen VS projects arranged so that the project references the DLL yet at the same time, VS knows where to find the source code, as I write I can't quite remember how to do that.
So, a Lib folder for DLLs works for me; I often call it "Shared Dependencies".
As for open-source source code, I don't have a standard way to version that because each project is structured differently and has a different build process. I don't like to tinker with the open-source project structure or build method because then, I take responsibility for it. If for some reason, it won't build, or builds incorrectly, or produces a faulty DLL, the cause would be exceedingly difficult to track down, and I'd have to get deep into troubleshooting all of that which I dont care about at all.
In a folder UNDER your solution directory, e.g. "external" or "library". That way your continuous integration system (or other team members) can do a pull of one root from your source control system and have everything they need.
In SVN, use svn:externals to pull that directory from a different root so you can easily share library DLLS (and library projects) between solutions.
In the office we have a share on the network for referenced asseblies. These could be 3rd party or assemblies of our own that could be shared between projects.
I also, don't like the idea of putting the dll files in source control. If all the developers have access to the share all will work fine.
The visual studio directory in My Documents seems like a logical place to put them. I don't know if it's the best or anything wrong with it but at least all the libraries are found in one place.
%USERPROFILE%\My Documents\Visual Studio XXXX\Libraries
At my company we place all our shared DLL assemblies onto a network drive in a folder called Assemblies. From there, we use SyncToy to mirror changes between that folder and a folder on our local development machines (in my case C:\Assemblies with subfolders for different versions or useful third party assemblies). Using the "Reference Paths" feature of Visual Studio projects makes it very easy to select different assembly versions based only on locations.
For projects at home, I would definitely go with the idea mentioned by Jeff M of placing them in the Visual Studio folder under My Documents.
I don't have a hard and fast rule on the location. However, I would encourage consistency!
For example, I needed to to this for a small tool I'm writing for a client at the moment, so I checked their other code bases in Bitbucket which seemed to use a dependencies folder in the solution folder (alongside the other projects), so I copied that.
I have a project that imports a DLL (written by me). Sometimes when an exception is raised within a method in the DLL, the host project opens a tab and let me see the code within the DLL. I can also put breakpoints within it.
But this behavior seems quite random, I cannot have it on purpose and not always works. Plus, I can't see the file name in the project explorer window.
Any help on debugging DLLs? Thanks
The enhanced debugging (for a dll not in the current solution) depends largely on whether you have the debugging symbols file (.pdb) in an obvious location - in particular, next to the dll itself. You can also load symbols manually from the modules window (when debugging, Debug -> Windows -> Module, right-click, Load Symbols From...)
What may be getting in your way here is a feature known as Just My Code (JMC). This is a debugger / CLR feature designed at limiting a users view of the world to just the code that they've written. The various ways in how a piece of code or DLL is determined to be yours or not can be confusing at times.
Next time you hit this problem, try disabling JMC and see if it fixes your problem
Navigate: Tools -> Options
Navigate: Debugger -> General
Uncheck the Just My Code option
On the managed C# program that calls the C++ dll,
right-click properties
debug tab
Tick Enable unmanaged code debugging
Hope this helps,
Tony.
To debug a dll it must have the pdb file with the debugging information that matches that dll.
Visual studio uses the .Pdb symbols generated by the compile process to enable you the dev to peek at the source when an exception occurs.
This information exists for two reasons. The first reason is for the compiler (i.e., a program that turns source code into an application, such as an .exe or .dll file) to use when it builds the application. The second reason is for people to use when debugging an application. The symbolic information is generated as part of the compilation of an application (if you set the compiler to generate symbolic information). This information can reside directly in the application files, or it can be written to separate symbol files. Where the symbols reside depends on your development application and the settings you choose. For example, Microsoft Visual Basic (VB) builds symbols right into the program files. Visual C++ (VC++) usually builds one or two separate files.
Symbol files have two file types—.dbg and .pdb. The .dbg files are in Common Object File Format (COFF), which is a generic symbol file description that doesn't include source line information; many debuggers can read these files. The .pdb files are a Microsoft format and contain a lot more information than the .dbg files. For example, source line information is available only in .pdb symbols. Symbol files that include source-code line information let you use the source code for debugging.
While it doesn't allow you to debug the code, Reflector is very useful when it comes to inspecting a DLL. The combination of a Stack Trace, the offending DLL and reflector will often get you to the nub of the problem.