I am working on an Xamarin.iOS application that is crashing when being deployed via an Ad-hoc process. As documented by Apple, when an application crashes, a .crash file is generated. The document also states that, as a developer, we must keep the dSYM folder.
Turns out, in my case, I (only?) have a mSYM folder.
Question
What is the difference between an MyApplicationName.App.dSYM folder and a MyApplicationName.App.mSYM folder?
.dSYM
A dSYM file is a "debug symbols file". It is generated when the "Strip Debug Symbols" setting is enabled in the build settings of your project.
When this setting is enabled, symbol names of your objects are removed from the resulting compiled binary (one of the many countermeasures to try and prevent would be hackers/crackers from reverse engineering your code, amongst other optimisations for binary size, etc.).
dSYM files will likely change each time your app is compiled (probably every single time due to date stamping), and have nothing to do with the project settings.
.mSYM
mSYM means MonoSymbolArchive.It contains debug info of mono.
Edit the iPhone release configuration in the csproj file to include <MonoSymbolArchive>True</MonoSymbolArchive> which will generate symbol data in bin/iPhone/Release/.mSYM
Related
I have a very small project (WinForms, it contains 2 folders and 10 classes, simple windows for input) and I want to publish it to folder as single .exe file.
When it is done the size of the file is 140MB. When I add "Trim unused assemblies" mark - 90 MB.
How can I add reduce the size this .exe file? I faced something like this before, and the size of the file was about 1 MB.
My publish config:
Configuration: Debug | Any CPU
Target framework: net5.0 windows
Deployment mode: self-contained (produce single file)
Target runtime: win x-86
Set the configuration to Release instead of Debug.
That will already add some optimazation.
The self-contained part should be disabled when optimizing for size. Disabling it will leave out the .net runtime, otherwise being embedded partially which saves space, but you must be sure the user has the appropriate .net runtime installed.
If your folders contain big files which are embedded, resources like videos, then there's nothing that can be done.
If it's a small project you can consider "just to compile it". If you're not using any non standard DLLs it result in a single (smaller) exe.
I am actually pretty fond of the self-contained option: it saves me the hassle of making sure the user/system has the correct .net vesion installed.
I use NSIS to create an installer for my project. Wishing to have as small a filesize as I can, I began looking into my project's dlls, included files and prerequesites and noticed the following are all different:
the minimal files required to run, as determined by educated guess + trial and error. I made sure the application works properly with this minmal set of files.
the files exported by the "Publish" fonction for click once deployment (excluding click once specific files)
the files in the release directory (excluding the pdb and vshost files)
It seems VS2015 generates an xml file for every dll. Some dlls I don't use and don't reference are copied as well.
My question is why is there so many unnecessary files and how can I configure VS2015 to not have them in /release?
If you set VS build log level to verbose you will see exactly what happends during build and why a file goes to release folder. Once you determine the reason, you may either change your project file to adjust predefined behavior or add post-build event to remove unwanted files produced by build process.
MSBuild file, located at "C:\Program Files (x86)\MSBuild\12.0\Bin\Microsoft.Common.targets" is very useful to dig into build process details as well.
However, if you indend to distribute the content of release folder to other machines I'd suggest you look at some installation software, like Wix, for example. Once you create a setup project which includes files you do want, there will be no need to fight for release folder content.
I have my auto generated Resource.resx file set up with keys and strings. I also have three other resx files for German, French and Spanish given to me from translators. I'm not able to get the localization functioning and I suspect that the resx files aren't being called correctly. I added them to the project by dragging them into the solution explorer under "Properties". I have a nagging suspicion that just dragging them in isn't creating the proper connections behind the scene.
Now It's totally possible my issue lies somewhere else. If anyone can tell me whether it's ok to add resource files this way or if not, what the correct way is, it would save me tons of time spent chasing my tail. Thanks!
Resx files in Visual Studio include a special tool which is run at build time and translates them into embedded resources. Right-click your original VS-created resx file and click Properties. You should see Build Tool or something similar. Also note the resource type (Embedded, etc.). Make sure that you match these settings for your manually added files.
Once this is set up, you will need to use the CurrentUICulture property to tell .NET to pick up the appropriate resources. You can choose to change the culture/language at install-time or run-time. Here is a comprehensive tutorial which describes the various options available to you:
WPF Localization Using RESX Files
That said, as a best practice, translated Resx files are generally deployed as satellite assemblies. The main application DLL/EXE contains only the language neutral resources file. Other resource files are compiled into separate assemblies and deployed side-by-side with specific naming conventions. This allows you to dynamically add translations, localizations, etc. even after the application is deployed. Here's an introduction: Packaging and Deploying Resources in Desktop Apps
I've added a bunch of files from my older project into my new project. They're still not playing an active role in my current code and there are missing classes that won't make them fully functional anyway, I just want them there so I can gradually rework each file to be compatible with my newest code. Is there a way tell the compiler not to pay attention to these C# files and report errors?
P.S: I'm using SharpDevelop
Have a look on the File Properties for
BuildAction Property
The BuildAction property indicates what Visual Studio does with a file when a build is executed. BuildAction can have one of several values:
•
None - The file is not included in the project output group and is not compiled in the build process. An example is a text file that contains documentation, such as a Readme file.
•
Compile - The file is compiled into the build output. This setting is used for code files.
•
Content - The file is not compiled, but is included in the Content output group. For example, this setting is the default value for an .htm or other kind of Web file.
•
Embedded Resource - This file is embedded in the main project build output as a DLL or executable. It is typically used for resource files.
use c# preprocessor directive #if then put that conditional variable inside Compiling/General/Conditional Compiling Symbols
http://msdn.microsoft.com/en-us/library/aa691099(v=vs.71).aspx
Although it is possible to give specific compiler instruction, I'd remove the files from the solution and put them somewhere safe in version control.
Having these files in the solution can easily be confusing when browsing the sources; I would not expect to have to check the BuildAction property of C# files to find out whether or not I am looking at something that is part of the build.
I read a lot of code in a source control viewer (looking a delta's and history), compiler options are not very obvious in environments like these.
Put them safe in source control and remove them from the build.
I'm still learning the basics of how VS2010 sees the world. Apparently, you can optionally "include" a file in a project. I'm a bit confused by this: If a file is version-controlled, AND the file is within the project directory, shouldn't it implicitly be "included" in the project? If not, what's the use case where a version-controlled file in the project directory should NOT be included in the project?
=== Addition ===
Based on the answers I've gotten so far, maybe I should rephrased my question: What does it mean for a file to be "included" in a project?
A project needs to know about files in order for compilation and distribution to occur. Just because you have a file that's under source-control, doesn't mean that it will be compiled if the project is unaware of it.
Also, you may want to include files as part of a distribution package. We do this quite often for our web projects that we distribute using web app gallery.
Conversely, you could have documentation or sql scripts that you version control, but do not want them to be part of the project.
EDIT: In answer to your update, what it means for a file to be included in a project is that the file is actually added to the .csproj or .vbproj file and will be used during compilation and/or distribution. VS does differentiate if the file is Content or if it needs to Compile it. This can be seen by clicking on the file in Solution Explorer and looking at the Build Action property.
No, you don't want random files that happen to be in the project directory included in source control.
We do sometimes put documentation (pdfs) or drawings/schematics in the project folder and under version control but you don't need them inside the visual studio project (especially when they are not being distributed because they are for internal use only).
Excluding the file from your project can be useful if the file is related to the project but not necessarily needed in the solution.
Example
If I need some test XML for an application that i'm writing; that is designed to normally be pulling this from a WCF service, it can be useful to keep that file in the directory for a development environment where I use IO to get the XML for testing, but I don't necessarily want it in my solution which is source controlled.
When you exclude a file from a project is no longer compiled or embedded, then when you want to include it again you can do so without having lost your settings.
If you e.g. copy a file (containing a helpful class which want to have in your project) into a folder of your project, then you will see ... nothing. You have to check the option "Show all files" of the solution explorer and the copied file can be seen, but it is still "greyed out". No you can choose the menuitem Include in project and that file will be integrated in your project and a pending change (add) for your source control is added too. Visual Studio doesn't include all files it can find in the project folder automatically to the project - and that is a good feature.
One of my colleagues explained to me a scenario in which a version-controlled file should NOT be part of the project. Here's the idea:
A developer writes some new code.
The code is experimental, and not intended to be part of the normal build.
The easiest way to exclude the file from the build is to NOT include it in the project, but still version-control it.
This way, the file can be shared with other developers, but not break the build.