Which folders may I not commit to subversion server?
I'm talking about an standard asp.net web application in Visual Studio 2.008. I think the bin folder because it's files are regenerated, is there any other?
We put this string as the svn:ignore property on all our projects:
*.pdb
*.exe
*.dll
debug/*
release/*
*.user
*.suo
obj/*
bin/*
obj
bin
VSMacros80
For any C# project I would recommend to ignore the following files/directories:
Visual Studio files to ignore
*.pdb — Files that hold states information when debugging.
*.exe — Executable binaries.
*.dll — Library binaries.
debug/* — Folder used by Visual Studio to store a lot of debugging information
release/* — Folder used by Visual Studio to store binary releases.
*.user — Configuration per user.
*.suo — Options settings per user stored in binary format.
obj — Folder used by Visual Studio to store binary objects used while debugging.
bin — Folder used by Visual Studio to store compiled objects.
VSMacros80 — Folder used by Visual Studio to store macros.
Other files to ignore
packages — Folder used for NuGet references.
*.log — In case of having logs written in the source folder (this should not happen).
Note: Remember to add these pattern to be ignored recursively.
Extra (copy-n-paste)
*.pdb
*.exe
*.dll
debug/*
release/*
*.user
*.suo
obj
bin
VSMacros80
packages
*.log
obj is another one, as they're debug symbols built during compilation.
Related
Currently I have to manually copy the platforms and imageformats plugin folders to the directory containing the .exe that MSVC compiled. This is very tedious as the output folders often get deleted if you're working on your CMakeLists.txt or changing compilation target.
Now qt_generate_deploy_app_script seems like an official Qt solution to solve this problem, but it does not work.
I have added the CMake bits to my CMakeLists.txt as stated
qt_generate_deploy_app_script(
TARGET HiveWE
FILENAME_VARIABLE deploy_script
NO_UNSUPPORTED_PLATFORM_ERROR
)
install(SCRIPT ${deploy_script})
I can see some generated deploy scripts appear under build\x64-RelWithDebInfo\.qt, but they do not seem to be run as no DLL folders get copied to where my .exe is.
Am I misinterpreting what qt_generate_deploy_app_script should do or is it simply broken?
If you want to Creat exe in windows From Qt project you should use windeployqt
To Deploy and create Exe output with QT in windows you should follow this way:
put your compiler path in your system path. for example, if you use mingw81_64, you should set it. something like Qt/tools/mingw81_64/bin
copy exe file that provides after building in release mode in one
folder and run mingw81_64 cmd (it has separate cmd) and cd to that
folder path
windeployqt app.exe
you are using Cmake So first create one release output and then use step 3.
This command will get all dll needs for your app and your exe will work .
if you use qml
windeployqt --qmldir (the path of its directory ) app.exe
and also see these youtube videos for more info:
https://www.youtube.com/watch?v=LdSTgR0xJco
https://www.youtube.com/watch?v=hCXAgB6y8eA
When you publish a .NET Core self-contained app right now, your exe is in the middle of a few dozen .NET Core runtime libraries, along with all the Nuget packages.
MyApp/
--ct/
--de/
--es/
...
--zh-Hant/
--Accessibility.dll
--api-ms-win-core-console.dll
... A dozen other .dlls
--MyApp.dll
--MyApp.exe
... Even more .dlls
I would like to set up publish so that these files are organized, like such
MyApp/
--netcoreapp3.0/
--nuget/
--MyApp.dll
--MyApp.exe
or even
MyApp.exe
MyApp/
--netcoreapp3.0/
--nuget/
--MyApp.dll
Alternatively, maybe there could be a way to change the directory of framework libraries in the .csproj <TargetFramework> tag? That way, I could use the framework-dependent publishing option and remove all the duplicate files.
If there is no constraint to use the framework-dependent publishing option you can publish with the PublishSingleFile option being true.
Your publish command would be
dotnet publish -c Release -r win-x64 /p:PublishSingleFile=true
Then in your publish folder you will find a "cleaner" result of an executable file, and some configuration files only (like appsettings.json or web.config). No nuget or runtime dlls.
I tried using Dotpeek and ILSpy.Net to decompile (my own code), they failed.
Do I need special obfuscation on distributed binaries of .Net Core 3 self-contained single executable ?
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.0</TargetFramework>
<PublishTrimmed>true</PublishTrimmed>
<PublishReadyToRun>true</PublishReadyToRun>
<PublishSingleFile>true</PublishSingleFile>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
</PropertyGroup>
</Project>
The single-file exe is really an unmanaged wrapper and ILSpy doesn't support decompiling this. But when you run the exe, it unwraps its contents to a temp folder. So you can find the managed dll there and decompile it using ILSpy.
To find the temp folder, you can use any tool that shows locations of assemblies loaded by a process. SysInternals Process Monitor (procmon) is a good one.
You can setup procmon to filter by your exe name, and when you launch your exe, procmon should show some events for assemblies being loaded from a temp folder:
You can browse to that folder and find your managed dll there. And you can decompile using ILSpy from that location.
I wrote a blog entry: https://eersonmez.blogspot.com/2020/02/ilspy-decompiling-net-core-self.html
I wrote a small dotnet tool after I stumbled upon this question and couldn't find a lightweight tool myself other than ILSpy.
You can install it using the following dotnet command: dotnet tool install -g sfextract.
After installing it, run it using the following command: sfextract application.exe -o output-dir
The bundle format for .NET 5.0 (bundle version 2) is identical to previous versions. .NET 6.0 (bundle version 6) has an additional field for each file entry containing the compressed size, since single-file applications can now be compressed using gzip by setting EnableCompressionInSingleFile to true.
https://www.nuget.org/packages/sfextract/
https://github.com/Droppers/SingleFileExtractor
Update 07/2022: .Net 5 single-file does not automatically unpack to the same temporary location as before. to force it to be unpacked you would need to add the following:
in the project file add these properties (according to theseMicrosoft docs):
<PublishSingleFile>true</PublishSingleFile>
<IncludeAllContentForSelfExtract>true</IncludeAllContentForSelfExtract>
Add an environment variable DOTNET_BUNDLE_EXTRACT_BASE_DIR with the location you want the files extracted to.
Update: One of the announcements made regarding .Net 5 states that the way single-file executables will be made would change, so this method will not work for them.
I wanted to add on #Eren Ersönmez's answer, that while ILSpy DotPeek don't support this at the time, since the self-contained single file is just a wrapper that contains all your DLLs and gets extracted on runtime, simply knowing where it is extracted to can save you using ProcMon or ProExp or windbg.
If you use windows you can go to c:\Users\{Local Username}\AppData\local\temp\.net\{Name of executable}
which should lead to somewhere similar to
c:\Users\alenros\AppData\Local\Temp.net\MyTestApplication
Launch your exe, and a folder with the same name will be created in that location.
The folder will contain randomly named folders. open the latest one and there you will find all your extracted DLLs, which can then be decompiled.
When I create a new Universal application (with VS 2017), I see "Microsoft.NETCore.UniversalWindowsPlatform" as a reference. This seems to just signify that a host of actual assemblies are implied (I see System.AppContext.dll, System.Collections.dll, and many more in the project bin\x86\Debug folder after building the project).
Do these files exist somewhere on my machine and copied to the bin folder when building? Or are they downloaded via Nuget when building? (I know that they are not the usual .NET Framework files in the usual .NET Framework locations).
How do I know which assemblies are implied by "Microsoft.NETCore.UniversalWindowsPlatform" without actually building? (Visual Studio must get this information from somewhere since it knows which to add to the bin folder).
If you want to reflect on these assemblies for a specific project (for example, as part of a code refactoring process) without actually building the project, where would you find these assembles?
UAP target platform (previously netcore50) (https://learn.microsoft.com/es-es/dotnet/standard/frameworks)
it's located in 'C:\Program Files (x86)\Microsoft SDKs\NETCoreSDK'
You can take a look at the nuget file 'C:\Program Files (x86)\Microsoft SDKs\NETCoreSDK\Microsoft.NETCore.UniversalWindowsPlatform\5.0.0\Microsoft.NETCore.UniversalWindowsPlatform.nuspec' and see his dependencies or using nuget.org (https://www.nuget.org/packages/Microsoft.NETCore.UniversalWindowsPlatform/)
Most of his dependencies are located in the same folder (C:\Program Files (x86)\Microsoft SDKs\NETCoreSDK), so you can take a look at the dlls (for example C:\Program Files (x86)\Microsoft SDKs\NETCoreSDK\System.Collections.Immutable\1.1.37\lib\dotnet\System.Collections.Immutable.dll)
When I release my Qt project, I want to redistribute the QtCore5.dll and Qtxxx.dll files.
How can I make myapp.exe to find them automatically?
The best way of doing this seems to be by editing a qt.conf file placed in the same folder as my executable.
myapp.exe is in c:\myapp\bin folder
The dlls are in c:myapp\common folder
"Better" way is to put your qt.conf into your resources :/qt/etc/qt.conf. This way has highest priority for resolving platform dependencies.
In our project we use cmake to generate necessary qt.conf file: in debug mode we put path to installed Qt binaries and in release - to local (deploy) folder.
Qt5xxx.dll files are linked, so you should place it in same folder, or make them available throught PATH environment variable. If you really want such exotic redistribution system (please, say real reason) - you may create your own platform-specific launcher, that will load necessary .dll's from any path.
Just put all required dll files into the same directory as your executable.
Note, that there are more files to distribute than just Qt*.dll - you will need proper plugin from platforms subdirectory and many more. Read Qt documentation on deploying application under Windows - it will teach you all required files.