Use case is something like this. We need to use the Bluez BT stack on linux. There is also dependency of an iOS app that controls BT testing on iOS (On mac). The execution flow triggers mounting of the file system from linux onto mac and tries to build the xcode project and use the .app file that gets generated after the build is successful
If the xcode build command is run manually on Mac directly, there is no problem
xcodebuild test-without-building -project ios_bluetooth/ios_bluetooth.xcodeproj/ -scheme
ios_bluetooth -destination id=uuid -only-
testing:ios_bluetoothUITests CONFIGURATION_BUILD_DIR=./Build/Products/Debug-iphoneos -
derivedDataPath ./ios_bluetooth/DerivedData/ arguments=TESTS_STA_BLUETOOTH_ON
From Linux, after the mount, by default it mounts to /var/root/ProjectFolder/Dependencies. Running the xcodebuild command results in issues in terms of permission. Issue can be see even if logged in as root on mac. Is there a way to circumvent this issue and get the xcode project to build? Any help in this regard is appreciated.
Currently I'm working on a project to deliver apps via MSIX packaging including python as one of them. I've already created an msix package for the same with below settings :
So the MSIX package displays the environment variables added to the system path
VHD has been mounted (staged) and registered on test machine, however I still cannot open python via cmd
I'm a bit new to the MSIX packaging tech, so any help would be appreciated.
Users to be able to run python from cmd.
Files that are packaged and deployed with an MSIX run inside a container. This means that these files will not be "visible" by default to tools like cmd or Powershell.
You need to define an appExecutionAlias in your package manifest. The following SO question has more details:
How to run an MSIX installed application from the command line
If you're using the MSIX Packaging Tool or Visual Studio to build the package, you need to manually edit the AppXManifest.xml file and add the appExecutionAlias element.
If you're using other commercial tools, you probably have a GUI option to include and configure it.
I'm trying to work on a repo that has a bunch of file with names like xxx:abc.js. Obviously the colon in the file name is invalid in windows.
So I thought if the files were on the Linux subsystem in Windows and if I was using VS Code's Remote extension, then it would be like I was developing in a Linux environment.
But the colon in those file names is still getting automatically removed by git when the repo gets opened by doing code .
Do I need to actually install the linux version of VS Code on ubuntu or is there some other way to make this work?
I upgraded to WSL 2, cloned the repo again and didn't have any issues.
I have a Visual Studio solution and am trying to build to run on a Linux installation of Docker. As part of the process I need to copy the XML documentation from one of the nuget packages for my Swagger documentation. On my windows development box, I am able to do this, but on Linux it is not working. The problem seems to be when I look at the lib folder for the nuget package on linux I see only a .dll while on Windows I see both .dll and .xml. Below is my restore command
RUN dotnet restore "src/Management/Management.csproj"
Why is the XML file not being extracted on linux?
On another note it seems like linux creates the directories using all lower case. So if I am extracting nuget package Test.MyPackage-3.4.3 it will be located on linux at /root/.nuget/.../test.mypackage/3.4.3. In my csproj file I am referencing the package using %(PackageReference.Identity) which returns the camel-case capitalization. Is there a work-around for this as well?
Not sure if it's still a relevant question.
There is an Env variable NUGET_XMLDOC_MODE which is set to skip in Docker image provided by Microsoft.
If you change it to ENV NUGET_XMLDOC_MODE=none in your Dockerfile it will fix the issue. However image build time will definitely increase so you can consider having dotnet restore as a separate step to enable caching.
More info can be found here
https://learn.microsoft.com/en-us/nuget/reference/cli-reference/cli-ref-environment-variables
In my linux machine, I'm trying to send a file over to a Windows machine via:
scp fileNameA user#windowServer:fileNameA
I get the following message:
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
What's prompting this message?
I've installed OpenSSH on the windows machine, and I can successfully SSH into it. I don't want to use WinSCP, FileZilla, etc, because I have to automate this in a script. This has to be done from the Linux machine, so I'm not interested in doing pscp from the Windows machine.
I have met the same problem today.
I think it is an issue in the new version of OpenSSH, which was published few days ago. I reverted previous version (v7.6.1.0p1-Beta), which was working correctly on my VM from https://github.com/PowerShell/Win32-OpenSSH/releases and problem was fixed without any changes in configuration.
I just fixed the same problem by moving my installation of OpenSSH from C:\Program Files\OpenSSH to C:\OpenSSH.
I had to first uninstall it properly using the provided script in Win32-OpenSSH and then follow back the information provided there https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH but only changing the path to C:\OpenSSH.
I met a similar issue today, trying to copy files to a Windows server running OpenSSH-Win64. I solved the problem by adding C:\Program Files\OpenSSH, which is the recommended installation location, to the Windows path:
Open the Control Panel, go to the System and Security section and open up System.
Click on Advanced System Settings and, in the System Properties dialog box, click Environmental Variables.
In the System Variables section of the dialog box, select Path and click Edit....
Click New, add the OpenSSH folder path and click OK to apply the change.
Then, do not forget to restart the OpenSSH service, either in the service management console or by running net stop sshd, followed by net start sshd in an elevated console.