What is an Assembly in VS2010? Is it the series of tests (which could be, for example, codedUITests) run in a specific test list from Test List Editor? If it isn't what is an assembly and what is the word for the test list?
All this is because I'm trying to research the answer to my main question.
A .NET Assembly is the ultimate output of a build. It can be a Class Library (.DLL) or a program (.EXE). Assemblies contain classes (and structs and enums).
when we compile any application in .net then it converts into assembly or exe.
I there is mail in application then it convert into EXE other wise it convert into assembly.
Its other name is portable executable file.
assembly has 4 parts
1:menifest
2:MSIL
3:metadata
4:Resources
Rajdeep
Related
I have two visual c++ projects in my solution. First one (lets call it Main) is native code. The second one (Test), has Main added as reference. Test contains unit tests to methods in Main.
When I add Main as a reference to Test and try to compile it - I get errors that the library could not be found. Does adding a project as reference , does not add the output target path of Main to the library directories of Test ?
I don't know what VC is exactly doing under the hood, but adding reference to a project doesn't seem to have effect of linking libraries unlike C#.
You can use the code from another project by including and linking via the usual method of c++.
We have a VS2010 C++ project with No Common Language Runtime Support set in its project properties. Then I see that it has a source file containing some managed code and the properties for this file has "/clr" flag set. So the project does not have a /clr flag but a file inside it has. I am confused as to whether it makes the project a mixed mode one? I can open the output file in ILDisassembler which makes me believe that it indeed is a .NET assembly.
This is entirely normal, a C++/CLI project very commonly contains a mix of native C++ and C++/CLI source code files. The setting in the General setting pages merely sets the default that the compiler will assume. But turning it on for each individual source file is quite valid and common.
Other ways to do this is to keep the native C++ code in a separate library project and link it. Or by turning on MSIL code generation on and off on-the-fly in a single source code file by using #pragma managed.
The linker doesn't have to be told about it, it can tell from the content of the object file. And yes, you will get a mixed-mode .NET assembly. With the C++/CLI bits compiled to MSIL and the native C++ code compiled to machine code.
I have a DLL file for old game(age of empires)
I just want to edit that file or see the source code.
I tried reflector toll and some others, but without any result
so, 1- how can I edit or see that DLL file??
2- can I know In what language that file was written?
It's sort of difficult. I mean you can look at the file with a hex editor, but it's not going to look nice. However, you can use 3rd-party tools in order to get as much info you can about the .dll:
Dependency Walker - useful to get the .dlls that your .dll depends on (and the functions that it need from there), exported functions, .... The bad thing is that last version is from 2006. A more actual replacement (written in .NET): [GitHub]: lucasg/Dependencies - Dependencies - An open-source modern Dependency Walker
[HeavenTools]: PE.Explorer - a nice tool (I'm not saying it's the best) that lists lots of info about the dll (sections, resources, ...) and it also has a disassembler (this reverse engineers the .dll and displays it in the form of assembly code). If you understand the assembly code you can then modify it (by modifying the corresponding bytes in your .dll), but that's for experts only. The problem is that it only handles 32bit (x86) .dlls, and the latest version is from 2009 :(
[MS.Docs]: DUMPBIN Reference - part of VStudio. Displays (read only) various information
For .dlls written in .NET, check [SO]: How to decompile a .dll file created in VS.net
Most likely it was written in C. The tools I listed can tell you more. You can also look with a text viewer at the .dll, inside it there might be references to source files (among all those unreadable symbols)
If the .dll has dependencies in form of msvcr###(d).dll (# sign is a placeholder for a digit) or vcruntime###(d).dll, then it's C, if it also has msvcp###(d).dll, then it's C++ (created with VStudio).
Adding to this:
For .net dlls an incredible program has arisen, made by JetBrains, called DotPeek which greatly simplifies decompilation of .net dlls.
I'm building a project which consists of two .net executables, and a class library with common components that the two executables share. For ease of distribution, I was hoping to be able to distribute the two executables without distributing the dll (grab & run distribution).
Is there any way to have visual studio compile the contents of the dll into each executable without manually copying the classes into each project (and thereby replicating the code in more than one place)?
Don't make it a DLL. Make it a static library instead.
Digging around on SO I found a duplicate question which stated the problem quite a bit more clearly than I did.
ILMerge seems to be the solution.
Static Linking of libraries created on C# .NET
I can't seem to understand how it works.
I see there is an option /assembly available to the Script# compiler which procuces a .dll file with the .js file as a resource. Here is an example from http://www.nikhilk.net/ScriptSharpIntro.aspx:
ssc /ref:sscorlib.dll /ref:Script.ScriptFX.Core.dll /debug /assembly:HelloWorld.dll /out:HelloWorld.js HelloWorld.cs
Can I get the same result using Script# Visual Studio templates? How do I enable this option for my Script# project?
There isn't a way to produce an assembly with script embedded in it.
I think the /assembly flag might be a remnant, or is there primarily for the script# compiler to know where the assembly produced from the same code as produced by the c# compiler exists.
If you want to embed the script in that assembly, you'll need to do a two pass c# build - in pass 1, there is a placeholder script, and then in pass 2, the real generated script.
Alternatively I can think of some approaches involving ildasm, add script resource reference, and then ilasm'ing to get back a new assembly.
What is your scenario? I am curious. I've debated whether to make the two pass build be supported out of the box... but never gotten around to it, since the embedding a script was a nice-to-have.