I am currently creating my own intellisense, and was slightly unsure on a point:
The VS Intellisense can look into referenced DLLs and pull out the namespaces, classes etc from it. Does it do this with reflection? What if I add a DLL made in java (if that can be done?)
for C++, does the intellisense simple scan header files you #include, and find available namespaces, classes etc from that?
I don't fully care about the exact implementation of intellisense in visual studio, but I am interested in how it obtains it's data.
Compiled .NET assemblies and Java classes contain all meta-information about classes and symbols that they define. Nothing like .h or .lib files is required to link against them. For these types of modules, significant amount information may be extracted directly from them.
I do not know if Visual Studio is using reflection to read metadata from managed assemblies, but reflection is certainly a correct mechanism to apply in this case. But also note that VS displays more information than there is contained in an assembly directly, namely, the /// doc-comments. These may come from source files in other projects in the solution, and from separate .XML files that come with assemblies.
For C and C++, the matter is different. There is little information available in a DLL alone. There are export symbols, but they do not usually signal whether a symbol is a function or just an extrn, and how many arguments and what types the function takes. C++ uses so called "mangled" names, from which some information may be gained. But most information that is available about a library is coming from header files. VS, as far as I know, parses sopurce files of projects and .h files included from code to get intellisense database. There are macros (#define's), and inline and template classes and functions that are not reflected in DLL extern symbols at all.
For both managed and unmanaged assemblies, sometimes debug information PDB files are available. Again, I am not sure, but I think VS is not using them for intellisense. This does not mean that you should not. There do contain extended information about external variables, classes, functions and methods. All in all, there is no "standard" intellisense approach, and you probably should consider using multiple sources for the symbolic source information.
Unfortunately, I do not know much about Java to give a detailed answer to that part of your question. Also, there is a popular IDE framework called Eclipse, but I have not looked under its hood. There must be some interesting parts hidden there, but do your own research.
A few useful references:
Visual Studio SDK. Even if you are not extending visual studio, you may want to read its documentation. It has a section on Intellisense. Also, look at open-source IDEs, such as Eclipse and #develop
System.Diagnostics.SymbolStore Namespace contains classes to access PDB files. In unmanaged world, use DbgHelp library, part of Windows SDK.
A utility called Depends was part of Win32 SDK, and is avalable separately now. It shows externals defined by an unmanaged DLL. This SO discussion reveals a few ways to access this information programmatically. DbgHelp contains functions to un-mangle C++ names, after you extract them from the PE export directory.
Related
I have a c++/CLI library that is in turn calling a c# library. That is fine, it is linking implicitly and all is good with the world. But for various reasons the libraries are not getting quite the prefect treatment by our automated build process, and the libraries are not finding each other unless we move the libraries to locations that we would rather not have them in, and would rather not fold into our build process.
It is suggested to me that we/I could write a post-build event that uses XCOPY. but lets say we don't want to do that.
Another suggestion is to explicitly load the dll. Windows says that to link explicitly "Applications must make a function call to explicitly load the DLL at run time." The problem is that Microsoft's example is not enough for my small mind to understand how to proceed with this idea. Worse, the only example I could find is out of date. Perhaps I am not using the right search terms but I am having difficulty finding more about it with google.
How do we explicitly Link a c++/Cli Library to a C# .dll?
----edit
OK, How do we explicitly Link a C++/CLI code, which exports a library using __declspec(), to a C# .dll.
There is no such thing as a "C++/CLI library", only assemblies are supported. There is no explicit or implicit linking, binding always happens at runtime. Assemblies are found at runtime by the CLR, the rules it uses to locate them are described in detail in the MSDN library.
Copying all dependencies into the same directory as the EXE is the sane way to go about it while you are developing the code. Well supported by build system, the C# and C++ rules are however different. C++ projects build to the solution's Debug directory, C# projects build to the EXE project's bin\Debug directory. So yes, altering a C++ project's Output Directory setting or copying files with a post build event is usually required to get everything together.
Hey i have done a few of decompiling in .net as i am learning c# so it helps me to see codes as it helps a lot. But lately i have come acrossed few program that i know are .net but in reflector show up as non .net assemblies. Here is the example of program named: Proxy Multiply.
I am not trying to do any illegal stuff or something. Just trying to learn. I have tried to google this but i was not able to achieve any good result.
Thanks
here is the link to image.
There are many .Net code protection alternative, that obfuscate the IL codes so that they are not that much exposed to IL disassembler application.
.Net Reactor
Themida
SmartAssembly
the list is huge . . .
many of the protector modify the Exe (PE Header info), .Net exe contains some extra MetaData that helps disassembler to identify it.
Download this little application it may tell you a little more about the exe.
Download PEiD 0.95
PEiD is an intuitive application that relies on its user-friendly
interface to detect packers, cryptors and compilers found in PE
executable files – its detection rate is higher than that of other
similar tools since the app packs more than 600 different signatures
in PE files.
PEiD comes with three different scanning methods, each suitable for a
distinct purpose. The Normal one scans the user-specified PE file at
its Entry Point for all its included signatures. The so-called Deep
Mode comes with increased detection ratio since it scans the file's
Entry Point containing section, whereas the Hardcore mode scans the
entire file for all the documented signatures.
My best guess the assembly you are looking for is Protected by .Net Reactor or Themida
I have same problem with dot net reflector before,
try JetBrains dotPeek version 1.0 Decompling(this application will show code that obfuscated)
Decompiling .NET 1.0-4.5 assemblies to C#
Support for .dll, .exe, .zip, .vsix, .nupkg, and .winmd files
Quick jump to a type, assembly, symbol, or type member
Effortless navigation to symbol declarations,
implementations, derived and base symbols, and more
Accurate search for symbol usages
with advanced presentation of search results
Overview of inheritance chains
Support for downloading code from source servers
Syntax highlighting
Complete keyboard support
dotPeek is free!
Just because it is .NET doesn't mean that you can just decompile it like that. They probably used ILMerge. That's not to say it's impossible but it will require more work.
See Is it possible to “decompile” a Windows .exe? Or at least view the Assembly?
I am quite new to Java (but having C#.NET experiences for many years).
Exists there a comparison of the most important differences between Java/JRE and C#/.NET?
Discovered a "strange" behavior in a Java "solution". Having several projects in my workspace. One of the packages does not compile. But this package also contains classes which are used by other projects without problems.
So it seems to me that even when a class does not compile in a package the other classes in that package can be used by other projects?
Is a package comparable to an assembly (.dll) in .NET? In .NET when a class does not compile no .dll will be generated.
The other strange thing for me is that .class files are also checked into the source control system. Maybe is this the reason why classed from a non-compileable package can be used. Does it really make sense checking in .class files to source control?
I am doing the reverse, learning C# and have some java experience. I would say packages in java are a little different than the .dll files generated in .NET. The packages in java are compiled into individual class files. So if one java source file doesn't compile in the package, you can use the other classes that did compile in that package (as long as the one that didn't compile isn't required by one of the other classes you are using). I would say it doesn't make sense to checkin the .class files to source control. I would just check in the java source files.
You may want to look at the folder structure that is generated by the package, that will give you a sense of what is being output. Typically it works like this if your package is com.mycompany.myapp then you'll have a folder structure of com/mycompany/myapp and inside myapp folder you'll see the class files. I'm sure someone else can provide more details, but I hope this helps you out.
Does it really make sense checking in .class files to source control?
In general the consensus is that source control is for source code and other inputs to the compilation process. Sometimes you might want to include a dependency (e.g. a 3rd party dll), but there's rarely a good reason to include your own output files.
Can anyone tell clearly about the usage of header files and namespaces in C#?
Because in C++ I was using ******.h files to read library functions. And when I saw some sample programs in C# they were missing, Can anyone tell me why?
I'm using C# to develop a custom tool for a CAD application. Whenever I use the appropriate function to open the file (CAD file), the compiler is giving me an error stating that the function names which I supply are not available in the context. Here what does meant by context?
When I opened the help file of that CAD application the function which is responsible for opening the file has bee mentioned under a header file called uf_part.h. But there is an namespace called NXOpen.
I used the namespace as using NXOpen in Visual Basic, isn't that enough? DO I need to supply that header file as well? If so, how?
C# is more "programmer friendly". When dealing with files of the same project, instead of manually specifying "header file" every time, it will go and look in all the project files for a match according to the namespace.
To understand this, do the following steps:
Start new project in Visual Studio. (No matter what type, WinForms or Console)
Right click the project and add new class.
In your main class note you can see the new class you just added, without adding any header.
How this is done? Simply by having the same namespace to both classes. The .NET engine is smart enough to link all those classes together.
Now, when it comes to external code meaning code sitting in a different DLL file the trick is to add reference to that DLL (in Studio --> Right click project --> Add reference --> Browse) then you need to specify you are going to use that DLL by adding a using statement on top:
using ExternalDllName.ExternalNamespace;
That's about it. Unlike C++ you don't need to have .h file as .NET will automatically search the referenced DLL files for a match.
There's no such thing as header file in .net, because all needed metadata is contained in referenced assembly itself.
Have you referenced needed assembly in you project?
Also please mind that there's no such thing as "function" in C#, only class methods (which means that you have to specify object or static class in you call).
Also: General Structure of a C# Program
Compilers for modern languages, such as C# or Java store within compiled files information on the classes and methods they contain, and this information can be used to check the correctness of calls made from one source file to another or to library classes.
When C was invented disk space, memory and CPU power were precious resources and this approach would not have been possible. Header files were introduced to allow the compiler to check that different source files conformed to the same interface. When C++ was invented the approach described above could have been possible, but I guess that it was chosen to stick to the C one for compatibility reasons.
There are a lot of little things I find myself re-writing here and there because they might be too large/complex to represent as a snippet, but realistically it doesn't make sense to make a stand-alone DLL out of it because we might only be talking a few dozen or a few hundred lines of code.
For example a little form which contains only a text box where the user enters a password and closes on {Enter}.
Or an extension method which can serialise/deserialise any object to/from a GZipped file assuming the object is marked as Serializable.
The list goes on. I have accumulated lots of little bits and pieces over the years and it's not organised in any neat way.
In C++ projects, I can write a lib file containing these bits of code which I can add to my compiler settings in such a way that any future C++ project I create has this lib included. I have done this with ATL and Boost.
I don't know of a way to do this for C# projects. Is it possible?
Edit:
If I make an assembly, I have to compile it to a DLL and distribute the DLL alongside my main executable. The DLL may be small or it may be quite large, I don't know. But I may only need to use a few tiny functions in that DLL for my project. In C++, only the functions I use are statically linked when I use the library, however if I distribute my software with a DLL then I have to distribute everything.
I know it is possible to merge the DLL with the main executable so that the user isn't aware that there is a separate library, however the whole DLL is still being packaged along with the executable.
Imagine I write a DLL with lots of my own maths, stats, file IO, image manipulation, serialisation, user IO, etc included. Nothing fancy, just some common things I find myself doing quite frequently. The DLL might be, say, 4MB.
Now I want to write a program which uses a tiny part of the DLL, and if I were to simply copy/paste the necessary code then my EXE would end up being, say, 700kB.
Are you saying that I either copy/paste the code I need, or I have to distribute a 4MB DLL along with my 700kB EXE?
Aside from using an assembly, the only way I know of is to create a link in your project to the source code in question. In visual studio the process is:
Project → Add → Existing File → Add As Link (the little down arrow:)
It is not possible at a source code level, although often requested (just Google c# #include equivalent). The only reasonable alternative that c# offers is compiling your common code as a DLL and adding a reference to it.
Note that although you can add a file to your project from another project, it will take a copy and therefore not maintain updates. I have used this to achieve the same effect 'manually' - when the common file is updated, I excluded it from the project 'referencing' it and then re-added to get a fresh copy.
UPDATE As commented below, you can add as a link - how cool! Why did nobody tell me.
We add a common directory to the overall includes path, then use
#include <somefile.cpp>
directly in our cpp files. It'll include the source straight in.