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.
Related
I have been using the Metrowerks Codewarrior IDE for many years. It's C/C++ compiler generates what Metrowerks calls 'browser info'. This browser info makes it possible to double click a typename/functioname and automatically the correct file is openend displaying the definition.
Now the mentioned IDE has the possibility to use external toolchains (compiler,linker etc.) by means of plugins. I have succesfully created compiler and linker plugins for both the Microsoft as the GNU toolchains. The only thing I don't know is how the generate the mentioned 'browser info'. Which command line do I have to execute to get the information I need?
Compiler flag /FR generates browser info files: /FR, /Fr (Create .Sbr File), and then you can use bscmake to compile these into a .bsc file.
However I've no idea how you'd consume these .sbr files or .bsc file in your plugin. I guess you'll need to find a DLL or COM interface from Visual Studio to give you something to work with. There are other options e.g. map files if they're easier to consume and have enough information for you.
I am writing a Visual Studio 2010 property sheet to integrate a complex 3rd party C++ library.
To determine what pieces of the library I need to link to my projects (as well as configuring various defines, includes, directories, etc.), my property sheet needs to determine the project's currently configured C runtime library (i.e. "MultiThreaded", "MultiThreadedDebug", "MultiThreadedDLL", or "MultiThreadedDebugDLL").
However, as a substantially similar question here on stackoverflow pointed out, this MSBuild conditional does not work:
Condition = " '$(RuntimeLibrary)' == 'MultiThreadedDLL' "
Another option was provided, but it was for a subsequent build task. I need this value before ever getting to the build.
I've also scoured Google and Microsoft's MSDN website looking for a way to get this value and have come up empty. Any ideas?
Since there was no way via MSBuild's XML to directly get the configured runtime library, I regex'ed the project file. Here is the XML PropertyGroup snippet to do this:
<PropertyGroup Label="UserMacros">
<RuntimeLibraryRegex>
<![CDATA[<ItemDefinitionGroup Condition=".*']]>$(Configuration)\|$(Platform)<![CDATA['">(?:.*\n)*?.*<RuntimeLibrary>(.*)</RuntimeLibrary>(?:.*\n)*?.*</ItemDefinitionGroup>]]>
</RuntimeLibraryRegex>
<RuntimeLibrary>
$([System.Text.RegularExpressions.Regex]::Match($([System.IO.File]::ReadAllText($(MSBuildProjectFullPath))), $(RuntimeLibraryRegex)).Result('$1'))
</RuntimeLibrary>
</PropertyGroup>
Now the Condition statement in the question will work as-is.
Also, please note that this MSBuild property group XML does not take into account runtime library default (e.g. if the project doesn't have the runtime library set) but can be made to easily.
Is it possible to compile libexif with Visual Studio 2010? I have been trying to do so and have been running into a whole slew of problems. I cannot find any information about whether anybody has successfully done this before. I know I can use MinGW to compile the library, but I am in a situation where I need it to be compiled with Visual Studio and then need to link to it from a Visual C++ app. Is this possible?
To answer your question: Yes it is possible... but it is a bit of a hack. Libexif uses functions that MSVC has chosen not to implement. See my working example VS2010 project below (if you don't like downloading files then skip to my explanation of what needed changing to get it to work below):
https://www.dropbox.com/s/l6wowl8pouux01a/libexif-0.6.21_CompiledInVS2010%2BExample.7z?dl=0
To elaborate, the issues that needed a "hack" (as hinted in the LibExif readme-win32.txt documentation) are:
Libexif uses inline in several places which is not defined in VS for C, only C++ (see this)
Libexif uses snprintf extensively in the code which is not defined in VS (see here)
You need to create the config.h yourself without a ./configure command to help you. You could read through the script but most of it doesn't make sense for Windows VS2010.
You will need to define GETTEXT_PACKAGE because it's probably setup in the configure file. I just choose UTF-8, whether that is correct or not I'm not sure.
There was a random unsigned static * that needed to be moved from a .c file to the .h file as C in VS doesn't allow you to create new variables inside functions in the particular way they were trying to do.
Read the "readme-win32.txt" file. Advice is:
hack yourself a build system somehow. This seems to be the Windows way of doing things.
Don't get your hopes up. The *nix way of doing things is the configuration script that needs to be run first. It auto-generates source files to marry the library to the specific flavor of *nix. The configuration script is almost half a megabyte. Three times as much code as in the actual .c files :) You cannot reasonably get that working without MinGW so you can execute the script. Once you got that done, you've got a better shot at it with a VS solution. As long as it doesn't use too much C99 specific syntax.
Whats the easiest way to find out what programming language an application was written in?
I would like to know if its vb or c++ or delphi or .net etc from the program exe file.
Try PEiD
of course if they used a packer, some unpacking will need to be done first :)
Start it up and check what run-time DLLs it uses with Process Explorer.
If that doesn't make it immediately obvious, search the web for references to those DLLs.
Most disassemblers (including Olly I think) can easily show you the text contained in an EXE or DLL, and that can also sometimes give a clue. Delphi types are often prefixed with T as in TMyClass.
If it's a small executable with no DLL references and no text you might be SOL. At that point you'd need to look for idioms of particular compilers, and it would be mostly guesswork.
There is an art to detecting what language a program was written in. It is possible but there are no hard and fast rules. It takes a lot of experience (and it also leads to the question "Why would you want to..." but here are a few ideas on how to go about it.
What you're looking for is a "signature". The signature could be a certain string that is included by the compiler, a reference to an API that is quite common in the programming tool being used, or even a style of programing that is common to the tools being used, visible in the strings contained in the application.
In addition, there are styles to how an application is deployed: various configuration files found in the deployment directory, dlls and assemblies and even images, directories or icons.
Java applications wrapped in a self-launching executable will contain references to java libs, and will likely have certain libraries or files included in the same directory that indicate that it's java.
As indicated in other answers a managed assembly will show certain signs as well: you can open it in Reflector etc. While it is correct that c# and VB are "interchangable" once compiled, it is not true that they are identical. If you use Reflector to disassemble VB code you will quite often see that the assembly references the Microsoft.VisualBasic.dll assembly. You'll be able to tell the difference between Mono applications because they will most likely contain references to the mono assemblies.
Many compilers assemble and link code in certain ways, and leave footprints behind. For example, examining a window executable using "strings: tab in Process Explorer, you'll see a lot of strings. Using these you may be able to determine programming styles, methods called, error or trace methods withint the exe.
An example is that compilers use different mechanisms for localization: Microsoft stores localized strings in XML files or resource files. Other compilers will use a different tactic.
Another example is c++ name mangling. The CodeWarrior compiler uses a different algorithm to mangle the names of the member variables and functions of a call than Visual Studio.
I suppose you could write a book on the subject of accurately determining the lineage of any executable. This subject would probably be called "programming archeology".
You could try using Depends to see what runtime dependancies it has, which might give some clues.
The easiest way is to ask the developer of the program. It does not require any knowledge and utility programs.
Determine Delphi Application
Use eda_preview270.exe (from here) or some other spy tool and check the window class names. If they read like TButton or TfrmBlubb, it's a VCL app. If there is an "Afx" in them, it's probably MFC.
Compiled languages (by this I mean no scripting languages, or Java, .NET, etc.) are compiled into CPU assembly instructions, which is essentially a one-way conversion. It is not usually possible to determine which language a program was written in. However, using a dependency walker, you could potentially determine which runtime library the program was loading (if any) and therefore determine which language it used (e.g. MS Visual C++ 9 uses msvcr90.dll).
you can check is that a .net assembly or not by trying to open with ildasm.exe tool
PE Detective works best for me.
In general, you can't.
If you can load it into Reflector, you know it is a managed assembly.
That's a good question. There isn't any general way to tell, but I bet most compilers and libraries leave a mark in the resulting EXE file. If you wanted to spend a lot of time on it, you could gather a bunch of EXEs written in known languages and scan for common strings. I would image you'd find some.
Dependancy Walker, which someone else mentioned would be a good way to look for telltale dependencies, like versions of MSVCRT, etc
i'd try running the .exe thru a 'strings' program to get assorted hints.
If I remember correctly PE Explorer Disassembler gives some information about compiler that creates given not .net and java binary, for .net use Reflector or ILDAsm tool
The easiest way that I found (at least in computer games) was to look in the "redist" folder nested within the game's main folder. It might be obvious to some of you that are more experienced in programming yourself, but the specific purpose of the MSI in this folder is to allow the setup.exe file to automatically install the prerequisites for the game itself.
For example:
In Empire Total War, there is an MSI called "vcredist_x86-sp1.exe". This indicates that the game/program was written in Microsoft's "Visual C 2005" in the .NET Framework (usually).
In fact, if you open the MSI/EXE, the installer should immediately indicate the language it's written in and which version.
The reason I'm familiar is because I code in C# and VB in the .NET Framework and we auto-install the prerequisites for our business app.
Hope this helps!
This I think is related to my use of the nlog C++ API (and my question on the nlog forum is here); the purpose of my asking this question here is to get a wider audience to my problem and perhaps to also get some more general ideas behind the VB6 IDE's failure to build in my particular scenario.
Briefly, the problem that I am having is that I am having trouble building VB6 components which reference unmanaged C++ components which have calls to nlog's C\C++ API (which is defined in NLogC.DLL). The build problems are not occurring during compile time, they are occurring when the binary is being built which suggests to me that it's some kind of linker type problem? Don't know enough about how VB6 binaries are produced to tell. The VB6 binary is produced, but it is corrupted and crashes shortly after it is invoked.
Has anyone had any similar experiences with VB6 (doesn't have to be related to nlog or C++)?
edit: Thanks for all the responses to this rather obscure problem. Still no headway unfortunately; my findings since I posted this:
'Tweaking' the compile options doesn't appear to help in this problem.
Adding a reference to the nlog-enabled C++ component from a 'blank' VB6 project doesn't crash it or cause weird build problems. So it isn't a 'native' VB6 issue, possibly an issue with the interaction between nlog and the various components and 3rd party libraries used by other referenced components?
As for C++ calling conventions: the nlog-enabled C++ component is - as far as I can see - compliant to these conventions and indeed works fine when referenced by VB6 as long as it is not making any nlog API calls. Not sure if the nlogc.DLL itself is VB6 compliant but I would have thought that that is immaterial since the API calls are being made from the C++ component; VB6 shouldn't know or care about what the C++ component is referencing (that's as far as my understanding on this goes...)
edit2: I should also note that the error message obtained during build is: "Errors during load. Please refer to "xxx" for details". When I bring up the log file, all that there is in there is: "Cannot load control xxx". Interestingly, all references to that particular control disappears from that particular project resulting in compile errors if I were to try to build again.
Got around the problem by using NLog's COM interface (NLog.ComInterop.DLL) from my unmanaged C++ code. Not as easy to do as the C\C++ API but at least it doesn't crash my VB6 components.
I would try tweaking some of the Compile options found in the Project, Properties menu, Compile panel to see if they yield any additional hints as to what is going wrong.
For example if you compile the executable to p-code rather than native code does it still crash on startup.
What error message do you get when you run your compiled binary?
I doubt the compiler/linker is the problem: project references in a VB6 project are not linked into the final executable. A project reference in VB6 is actually a reference to a COM type library (which may or may not be embedded in a .dll or other binary file type). Project references primarily serve two purposes:
The IDE extracts type information from the referenced type libraries which it then displays in the Object Browser (and in the Intellisense drop-down)
At compile-time, the compiler extracts the type information stored in the referenced libraries, including the CLSID of each class that you instantiate, and embeds this data into the executable. This allows your executable to create instances of classes contained in the libraries that you referenced.
Note that the compiled binary doesn't link to any code in the referenced libraries, and it doesn't even contain the filenames of the referenced libraries. The final executable only contains the CLSID's and other type information that it needs to instantiate COM objects at run-time.
It is much more likely that the issue is with NLog, or with how you are calling it from your code, rather than something gone awry in the VB6 compile process.
If you think it might be a linker problem, this should crash it the same way:
create a new standard project (of any kind)
add a new module and copy the "declare"-statements into it
compile
If it doesn't crash it is something else.
It would help an exact description of the error or a screenshot of what going on.
One thing to check is wherever NLogC.DLL or the C++ DLL you built have the correct calling convention defined. Basically you can't have the DLL function names mangled or use anything but the STDCALL calling convention. If the C++ DLL has not been created with those two things in mind then it will fail to work with VB6.
MSDN Article on Calling convention.
"Cannot load control xxx" errors can be caused by .oca files which were created from a different version of an .ocx than currently used. If that is the case, deleting the .oca files helps.