I've noticed in Visual Studio some classes have an option that if you look at their definition, you don't actually see the definition only the class's declaration and some documentation, for example:
Does anyone know how to make my classes lead to a similar file?
Thanks
I think some basic has to be explained here.
Source code is bunch of C# files (.cs). This is where code of your classes is
When you compile source code you will get an assembly (.dll). Assembly contains metadata about your classes and compiled binary code, but not actual source code.
When you compile your source code, Visual Studio produces also .PDB file along with your assembly. PDB files allows you to see the source code of the assembly. PDB files are necessary for debugging. It is somewhat similar to javascript source maps.
Now, when in Visual Studio you Go to Definition of a class or a method , then following can happen:
The class is in your solution -> you are navigated to the source code file (.cs)
The class is defined in a referenced assembly and PDB file is available -> you are navigated to source code extracted from the PDB file. You can debug it, (however, you cannot edit it).
The class is defined in a references assembly and PDB file is NOT available -> you are navigated the assembly metadata. (this is what happend on the picture you've posted)
So answer to your question is: isolate your assembly from .PDB and source code. However, you should be aware, that there are tools, that can reverse engineer C# code from the binary code that is in the assembly. It will be not exactly the same as your original source code but very similar.
This is the default behavior if Visual Studio can't find the PDB file which contains information on the location of the actual file and the line numbers in the compiled code.
This should work if you include a referenced assembly from another solution, and then rename the folder where the code is contained. Remove the PDB from the referenced location, and you will see this outline.
For you as a developer, showing the code is a feature: it helps you to debug and analyse problems in assemblies you have built. So I would advice to keep it on. Don't worry too much about other developers, if you don't send the PDB file, they won't see the code from Visual Studio. They still can read the assembly's source code using Reflector for example.
Related
I am trying to create a batch script to produce localised versions of resource files. Following the various MSDN articles I compile the resources using resgen
resgen.exe "My.Resources\resources.ja-JP.resx" "My.Resources\obj\resources.ja-JP.resources"
I then use Al to create the dll
al.exe" /culture:ja-JP /keyfile:"ResourceKey.snk" /out:"bin\ja-JP\My.Resources.resources.dll" /platform:x64 /template:"bin\My.Resources.resources.dll" /embed:"My.Operator.Resources\obj\resources.ja-JP.resources"
All of this works without error and produces a signed dll. However, when I use a test program to test it (again taken from an MSDN article) it does not find the localised resource but displays the generic language fallback instead. (if I swap the localised dll for one produced in Visual Studio all works fine)
Looking at the output in visual studio, it loads the dll withno errors.
Looking at the ResourceManager object in the debugger it appears to have loaded the fallback resources twice (but this is probably irrelevant)
The Fusion log is silent on the matter (i.e. no errors relating to the resource dlls.
Does anybody have any suggestions about what I am doing wrong? Is there any way of persuading .Net to provide further information about why it is ignoring the localised dll?
Thanks.
I think that the /template switch to al.exe should specify the executable file of the application.
It looks like you have specified the neutral resource file.
If that is not the error, I suggest that you build your project from the command line with msbuild, and examine the exact command lines which it uses.
I want to decompile .pdb files so I can see where references are pointing to. The projects are being built from a build server. I also want to explore the possibility of using these to index a codebase.
I cannot seem to find any tools to decompile and view the contents.
I have found this stack post Help me to read .pdb file but the first recommended example is missing (Producing an XML would be ideal) && the second will not build on my machine.
I have also tried using reflector to open the file but does not work.
Can anyone provide insight into how I can deompile a .pdb file?
You can try using Mono.Cecil project. It's open source libraries for decompiling .NET assemblies to IL code. It also allow to work with .pdb files of .NET projects. Mono.Cecil doesn't use reflection, it reads assembly as byte stream.
For decompiling assembly to C# code, you can look to the ILSpy project. It's also open source project and it uses the Mono.Cecil library inside.
This has caused me a day's worth of work at this point. In visual studio I can add a reference to a custom-made .dll file. Once the reference has been added, I can call the .dll file:
someClass_inDll sc = new someClass_inDll();
sc.someVoid_in_dll();
Simple, right? No assembly use, invoking etc. needs to be done. I would like to be able to do this exact same thing using CodeDom! So, assume I have a custom .dll file (already made and on my hard drive), I have been adding the full path to said dll file to the list of codedom references. However, the actual .dll file is not being compiled with my project (as it is with visual Studio).
Can someone please tell me why this is? It's making no sense to me what so ever.
I do NOT want to add the .dll file as an embedded resource because the only way I could call functions in the dll file would be to invoke it which is something I'd rather not do for personal reasons.
I really appreciate the help everyone!
Thanks,
Evan
I am not sure I understand what you are asking, but here goes...
Visual Studio is copying all of your references into the output directory that are set to "Copy Local" in your .proj file AFTER compilation. The compiler itself is not concerned with the deployment of your dependencies, this is what msbuild is for.
So, when you add a reference to the CompilerParameters of your provider, it will use the reference to build the executable, but you will have to copy it yourself.
I have two projects A is of type webservice and B is of type class library project. Project A refrences B.dll. In A when I right click some method and click Go to defenition,if it is defined in project B,it should open the source of project B.I have B.pdb already added to project A. Any help?
Do you have the source code of B.dll included to your project?
Unless you have the source code of that library, you cannot view the source code. However, you can see the definitions like in the same way as you can view the definitions of FCL.
About PDB: PDB files map an assembly's MSIL to the original source lines. This means that if you put the PDB that was compiled with the assembly in the same directory as the assembly, your exception stack traces will have the names and lines of the positions in the original source files. Without the PDB file, you will only see the name of the class and method for each level of the stack trace.
I took the definition from this SO link. Said by Omer van Kloeten.
Has anyone experienced this or found a solution? I have tried the following:
Referencing the output dll directly without moving it
Uninstalling the output dll from the GAC
Neither option made a difference. Please note that the generated XML doc has the same name as the dll and is included with it.
Ah ha. I found the reason why this was occurring.
If you referencing your ILMerge project within Visual Studio (i.e. as Add Reference -> Project) then Intellisense will not use the generated XML doc.
To solve: In your post-build step copy your output files to a common directory (e.g. Reference Assemblies) and then link against the DLLs. You can still have the project in the solution, however you must setup the project dependencies so that it will build if you have made changes.
HTH,