Is it possible for a VSIX to record the executable bit on a file (i.e. file mode, linux execute bit) such that when the VSIX is installed, linux/mac will recognize the file is executable?
Because VSIX is simply a ZIP package, your wish comes true as long as 1) everything on disk is set up properly before you run vsce package or vsce publish, and 2) you run that on macOS or Linux.
The same packaging process just won’t work well on Windows.
Related
I have the following as part of a "Deploy" project which I run manually from a batch file using msbuild.exe (VS2017).
<Target Name="ZipRelease"
DependsOnTargets="getversion;gettime">
<MakeDir Directories="$(ReleaseDir)" Condition="!Exists('$(ReleaseDir)')" />
<ZipDirectory Condition="Exists('$(BuildDir)')"
SourceDirectory="$(BuildDir)"
DestinationFile="$(ReleaseDir)\$(MODNAME)-$(DLLVersion)_$(CurrentDate).zip" />
</Target>
On one PC I use the Community Edition of VS2017. I may also have installed VS2019 on that machine (no way to check for a couple of weeks). Crucially the batch file forces the use of VS2017. On another PC I have VS2017 Professional.
On the PC using the Community Edition, this task creates correct zip files which use forward-slashes as the path separator. On the PC using VS2017Pro, the task creates zip files with back-slashes which is obviously against the spec and causes lots of problems (the resulting ZIP is deployed on Linux as well as Windows).
This thread indicates DotNet 4.6.1 or later fixes the path separator used when creating ZIP files. I specify ToolsVersion="15.8" as part of the Project configuration (minimum version for the ZipDirectory task), but how do I force the DotNet version for an MSBuild Task?
I've tried uninstalling all earlier versions of Dotnet SDK/target framework from the PC to no avail.
There's also an override documented (Switch.System.IO.Compression.ZipFile.UseBackslash), but that only applies to applications, not MSBuild Tasks.
As seems usual with MS stuff, there's inconsistencies everywhere and my Google skills are insufficient to find an answer so grateful for anybody being able to point me in the right direction.
Installing VS2019 fixes it.
It seems my script automatically configures itself to use the newest version of Visual Studio instead of forcing itself to VS2017 as I had originally stated.
Even though all DotNet version numbers as reported by the build script for its runtime framework are still the same, something is obviously different between running in a VS2017 vs VS2019 environment.
It would be very very nice to figure out exactly what and whether it's possible to force the VS2017 intall to use that as well..
Try to use
<ZipDirectory Condition="Exists('$(BuildDir)')"
SourceDirectory="$(BuildDir)"
DestinationFile="$([System.String]::Copy($(ReleaseDir)\$(MODNAME)-$(DLLVersion)_$(CurrentDate).zip).Replace('\', '/'))" />
Actually, all my agents are using back-slashes for path. And windows always uses back-slashes for path, so I wonder if you have made some changes to your windows or VS IDE to use forward-slashes for that PC.
Linux uses forward-slashes but Windows do not use that by default.
You can open the folder of the C disk to check whether the path uses forward-slashes. And make sure whether you have run some cmd commands to use that.
Open VS IDE, compare with the two versions from the two PCs, open Extensions-->Manage Extensions-->Installed to check whether you have installed some extensions to cause that.
When I build my project in command line, everything works fine. But when I tried to generate a .sln file for the project by running msbuild /t:SlnGen /p:Platform=x64
at the command prompt, and then click build in VS (debug, x64), I got an error saying it can't copy a dependent binary folder because it is not found. Since my project is on CBT, I have x64, x86 and Any-CPU platform settings. My project used to be built on CoreXT. My suspicion is VS build doesn't handle the output path of the dependencies correctly.
Then how can I build the solution only on x64 through VS?
Any hint will be very helpful!
I have a WinRT app built with VS2013 using C#. It uses SQLite so it needs the sqlite3.dll included in the project to be in the output directory. I included that DLL in my project and set it to always copy to the output directory. The problem is VS2013 copies it to the Debug directory, but not the AppX directory underneath Debug, which appears to be the WinRT output directory. Because of the the app fails because it can't find sqlite3.dll, which is up in the parent Debug directory instead of the AppX directory.
For now I'm just hand-copying the DLL into the AppX directory. What's the best way to fix this problem so that the DLL is copied to the correct directory?
In your project's Properties window choose Build Events tab. On Post-build window include similar string (please, mind to change the path to sqlite3.dll):
xcopy /Y $(ProjectDir)3DParties\sqlite3\$(PlatformName)\sqlite3.dll $(TargetDir)AppX\
Or even better option. This page https://www.sqlite.org/download.html contains section named "Precompiled Binaries for Windows Runtime" where you can download VSIX package. When you install this package into your system, you can simply reference sqlite3.dll for all target platforms (ARM, x86, x64) including all necessities automatically like this: Add Reference -> Windows 8.1 -> Extensions -> SQLite for Windows Runtime (Windows 8.1)
I can't be sure this is the "right" solution, but I set the file's property to Content/Copy-if-newer.
THEN what I've found is that if the AppX directory is already there, VS doesn't update it, just as you describe above, BUT if you delete the Appx directory then VS will create it from scratch and add the necessary files.
Not as good as having everything automated, but beats hand-copying.
I am developping a multi-platform application under Linux. To build the Windows versions, I make use of cross-compiling with MinGW. For "first" tests, I am using wine. First, I have started with MinGW32 and wine configured for Windows XP.
I need to build tier dll and my own dll. Build is alright. If I copy them in C:\windows\system32\ and run my application which use these dll under wine, it does not find them. If I put a copy of the dll in the same directory than the application, it works.
I have tried :
~/.wine/drive_c/windows/system32/
/root/.wine/drive_c/windows/system32/
If I run the explorer (wine explorer), and browse into C:\windows\system32\ , my dll are not there !
Thus, how can I make wine find home made dlls ? I have had a look at winecfg and winetricks, but they are of no help.
Cheers,
Laurent.
Try creating an installer for your application, using nsis or something, and creating a package that includes your dll and application. Then install that installer using wine.
I have made an application using Qt 5.0.2 and made its build using inno setup. The application is successfully installed and launched at my system and worked fine.But when i installed it on other system, application is not installing or launching also no error showing. Please help me guys... What to do
If you are using visual studio to build your application you will probably need to install vcredist_sp1_x86.exe on the destination machine. You can find it somewhere in the installation folder of Qt. You can add it to the list of files in the Inno script, and add entry in the [Run] section. Also make sure you have included in your setup script:
Qt5Core.dll
Qt5Gui.dll
Qt5Widgets.dll
libGLESv2.dll
icuuc49.dll
icuin49.dll
icudt49.dll
D3DCompiler_43.dll
plugins/platforms/qwindows.dll ->should be installed in platforms/qwindows.dll in the destination folder. The same applies to imageformats plugins if you use them.
If you think there are too much dlls you will need to rebuild Qt with other configuration options, but that's another story...