I am currently working on an iOS project using the Unity framework.
When I export an Xcode project from Unity, there are a whole bunch of files exported.
Besides some source files, there are also .dll files for the Mono project.
But there are also .dll.s files.
For troubleshooting, it would be great to know what they are used for.
There is one .dll.s file for every dll, so it could be some sort of source which is compiled into the dll?
When there are exceptions somewhere in the code, Xcode often jumps into one of these .dll.s files and it looks as if they contain some sort of assembly code.
Directions would be nice, Google isn't really helpful here ...
TIA,
best regards,
Flo
They're the IL code in the dll files compiled into arm assembly. This is the code that eventually end up in the final app binary.
Related
I have a file-translation library in the form of a Win32 EXE and a stub DLL that feeds parameters to it. I have written a lightweight (~500 lines) VB.net app that creates the file to be translated, then calls the DLL to launch the EXE. Unfortunately, this results in my EXE, their EXE, the DLL and another supporting file. I'd prefer to have a single file.
Following the basic idea here doesn't seem to help - I need to have all three files able to see each other, and it's not clear how to do this from those examples. I've also seen this, but again, this appears to be running an EXE that is "beside" the .net code, not embedded within it.
So, is there a way to run the EXE/DLL/supporting file "in situ"? Are the Assemblies ultimately a directory structure where I can run the EXE? And if so, how does one find/refer to these files?
I'm building a windows mobile 6.0 application and I wanted to use restsharp library to consume data from a rest service. I've found information that RestSharp can be compiled for compact framework 3.5 (as is not available from the official site).
But, does anybody have successfully compiled the assembly for CF? If yes, could anybody provide a link to download the assembly. Thanks
I do not know a download location for the ready-to-use assembly.
I would start a new CF2 project and in another instance of VS open the original restsharp solution. Additionally open two file explorer to copy files of the restsharp source to the new CF2 project directory. You should maintain the same solution layout and folders (if any). Then copy the files over to CF2 dirs and use Add Existing Files in the CF2 solution. You need to use the same namespace and project and solution names (makes live easier).
Now try to compile. If you are lucky, everything compiles without error. But mostly you have to either adjust code or write CF2 compatible wrappers. If there are two many FullFramework constructs that can not be 'emulated' in CF2, you may have to give up. But as you said, there are CF compatible sources.
You mentionend CF3.5 and asked for CF2. Possibly RestSharp will only compile as CF3.5 assembly.
See also: RestSharp: Don’t Serialize null Properties
BTW: the GitHub repo (https://github.com/restsharp/RestSharp) shows a CF solution file RestSharp.Compact.sln and RestSharp.Compact.csproj. These should work with VS2008.
This is driving me crazy. I have developed a .NET COM DLL that is used by a VB6 DLL wrapper in order to update and replace some legacy functions in an application.
I am now trying to remove the requirement to use regasm on client machines so have worked out how to do that on a test DLL which all works fine.
I branched the DLL just in case and added an app.manifest file. Everything else worked out fine and I got it all working. The manifest is embedded and Visual Studio 2012 generates a mydll.dll.manifest file in the release folder.
Then I went back to the original trunk and added an app.manifest file (no point in merging as there were no code changes). I copied the contents of the branch into the app.manifest file and built the release version. The manifest is embedded in the DLL but no mydll.dll.manifest file is generated.
I know that it's not strictly necessary to have the mydll.dll.manifest file but I'd like things to be consistent (and for some reason the test process doesn't produce the same results with the trunk version) so how can I force it to be created?
This is a VB.NET DLL project so it doesn't have (or I can't find) the 'Generate Manifest' property drop down mentioned in the first answer here. How can I set this? Or is there a way to set it by editing the project file directly?
References:
Original walkthrough article and some corrections.
Overview by Junfeng Zhang in two articles plus a useful tool
You are making a fairly common mistake. A reg-free COM manifest helps an application find a COM server without looking in the registry to locate the DLL. Embedding the manifest in the DLL is like trying to solve the chicken and egg problem, Windows cannot possibly find that manifest if it cannot locate the DLL first.
The manifest needs to be part of the client app. Which is tricky since it is VB6, it doesn't support embedding manifests in its executables.
You could tinker with the mt.exe tool, an SDK utility that supports embedding manifests in an executable. You'd have to run it by hand after building the VB6 binaries. That's unfun and very likely to cause trouble when you forget. It is in general not a joyful tool to use, documentation is meager, incomplete and unhelpful, a chronic problem with manifests.
The fall back is a separate app.exe.manifest file, what Windows will look for next when it cannot find a manifest embedded in the executable. Where "app.exe" must be renamed to the name of the VB6 program. The EXE, not the DLL. This now also gives you a chance to avoid having to register the VB6 DLL, presumably what you really want if you truly want to make your program run reg-free. The disadvantage is that it will not work when you debug your VB6 program, wrong EXE. You'd also need a vb6.exe.manifest, located in the VB6 install directory.
Needless to say perhaps, very hard to get ahead with VB6 here. It just wasn't made to help you do this, they didn't have a time machine in 1998.
I have to admit that I don't know VB at all, but in the case of C++ and C# Visual Studio projects I previously had to resort to calling mt.exe in a post-build step in order to get the DLL manifest I wanted. Maybe that workaround would work in your case as well?
The big picture: what I am trying to accomplish is writing code in both C# and C++, to strike a good performance/productivity balance. It is not for code reuse reasons; I just want to be able to write new code in native C++ when it suits me, without committing to all its horrors.
I have a solution with 4 projects:
GUI: C# WPF interface
Logic_Cs: C# DLL, high level reference implementation of game logic
Logic_CLI: CLI DLL, interface between managed and unmanaged code
Logic_Cpp: C++ lib with native implementation
At some point, all of this was working just fine. In my GUI project I could switch between C#/C++ implementation merely by using the namespace from the appropriate DLL.
Then I apparently changed something, and now I can not get the namespace in the Logic_CLI project to be recognized in the GUI project, even though the Logic_Cs namespace still works just fine.
Yes, I added correct references, set dependencies, rebuilt AND recreated my entire solution structure from scratch; nothing helps.
I notice the C# DLL builds to a folder in its own project directory, while CLI builds to the solution directory; but the GUI application seems to look for the DLL's in their correct directory anyway, and im not getting any complaints about the DLL; it just refuses to import the namespace from it.
Earlier, when all this was working, I wasnt explicitly exporting anything from the CLI DLL; nor am I doing so for the C# DLL. It should 'just work', no?
We have a Powerbuilder 10 application that is using .Net COM assemblies. We are trying to embed the manifest in the PB application (to invoke COM assemblies without registration). The merged manifest file has added sections for dependecies on the .Net COM assemblies. We have tries various tools to inject the new manifest with different results
- using GenMan32 to inject truncates the application from 6MB to 45KB.
- using ResourceTuner, the file size looks okay, but trying to launch application gives "Fatal Disk Error".
Any suggestions on invoked .Net ComEnabled assembly from PB without registration?
Have you tried it with an external manifest and ensured that works? If an external manifest doesn't work, then the manifest information isn't correct.
Once you have a valid external manifest, you might try the Manifest Tool (MT.EXE) from the .Net SDK. It works well with true EXE files. As Terry noted though, the PB generated executable contains additional information that tools that manipulate the EXE need to respect or they will break it.
http://blogs.msdn.com/patricka/archive/2009/12/09/answers-to-several-application-manifest-mysteries-and-questions.aspx
This is more a redirection than an answer. One thing you need to be aware of is that PowerBuilder produces executables that do not follow standards for Windows executable files. Essentially they are a bootstrap routine to load the PowerBuilder virtual machine, plus a collection of class definitions (objects). The cases you've brought up are not the first I've heard of where utilities meant to modify executables don't work on PowerBuilder executables.
As for a positive contribution on what other directions to follow, I don't really know enough to give qualified advice. If it were me, I'd try to register the COM object if ConnectToNewObject() fails, but I've got no idea if that possible or if that route is a dead end.
Good luck,
Terry.