I'm tinkering with Xamarin.Forms on Visual Studio Community for Mac version 7.3.2
What I'm trying to accomplish is to convert all managed code to native executables using these options in MyApp.Droid.csproj:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<EmbedAssembliesIntoApk>false</EmbedAssembliesIntoApk>
<AotAssemblies>true</AotAssemblies>
<EnableLLVM>true</EnableLLVM>
</PropertyGroup>
EmbedAssembliesIntoApk does embed the assemblies into the apk so I've set it to false, because those are precisely what I want to get rid of.
I've also set AotAssemblies and EnableLLVM to true so the managed code is AOT compiled and converted to native code.
Those options build a signed apk with the lib/ folder containing the files below and no assemblies folder, which is what I want.
lib/
armeabi-v7a/
libgdbserver.so
libmono-profiler-log.so
libmonodroid.so
libmonosgen-2.0.so
The problem is that if I clear the application data on the device and try to run the app again it won't start giving me some error saying 'no assemblies found' or 'conflicts between different versions of the same assembly'
Is it possible to build and ship a Xamarin.Forms application for Android without any managed assemblies, but only native executables?
Update:
I tried Xamarin Studio and it adds the option BundleAssemblies, so the project setting are as follows but Xamarin fails build the target:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release</OutputPath>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<AndroidManagedSymbols>true</AndroidManagedSymbols>
<AndroidUseSharedRuntime>false</AndroidUseSharedRuntime>
<AndroidLinkMode>Full</AndroidLinkMode>
<EmbedAssembliesIntoApk>true</EmbedAssembliesIntoApk>
<AotAssemblies>true</AotAssemblies>
<EnableLLVM>true</EnableLLVM>
<BundleAssemblies>true</BundleAssemblies>
</PropertyGroup>
With those option on Visual Studio I get this executables:
lib/
armeabi-v7a/
libmonodroid_bundle_app.so
libmonodroid.so
libmonosgen-2.0.so
plus a bunch of files something.dll.so
Related
When I deploy (or archive) my Xamarin.Android application and attempt to use the .APK file in a UI test I am met with this error. My configuration is exactly how it should be for a release build.
(PLEASE READ TO THE END)
System.Exception : Mono Shared Runtime is not supported. This can be resolved by changing the project configuration or using a Release build.
Stack Trace
ApkFile.EnsureNoSharedRuntime()
AndroidAppInitializer.PrepareApkFiles(IAndroidAppConfiguration appConfiguration, ArtifactFolder artifactFolder)
AndroidApp.ctor(IAndroidAppConfiguration appConfiguration, IExecutor executor)
AndroidAppConfigurator.StartApp(AppDataMode appDataMode)
AppInitializer.StartApp(Platform platform)
Tests.BeforeEachTest()
AndroidManifest.xml
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>portable</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release</OutputPath>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<AndroidManagedSymbols>true</AndroidManagedSymbols>
<AndroidUseSharedRuntime>false</AndroidUseSharedRuntime>
<AotAssemblies>false</AotAssemblies>
<EnableLLVM>false</EnableLLVM>
<AndroidEnableProfiledAot>true</AndroidEnableProfiledAot>
<BundleAssemblies>false</BundleAssemblies>
<EmbedAssembliesIntoApk>true</EmbedAssembliesIntoApk>
<AndroidSupportedAbis />
</PropertyGroup>
This is ridiculous I have seen questions about this going up to FIVE years back and many unanswered. If someone knows a fix to this please let's help me and everyone else having this issue.
I literally created a brand new project with VS2022 and even on the release config. this error still shows on both emulated and physical devices.
Update: When the project is built and signed with Azure Devops the .APK file works on UITest. I am convinced this is a Visual Studio APK deployment problem.
We've had similar problems before, you can try the following methods:
1.in release mode,please make sure you uncheck use Fast Deployment(debug mode only);
2.make sure update your nuget to the latest one,the old Nuget had this issue；
3.If the problem persists,you can try the following workaround: set
<AndroidUseAssemblyStore>false</AndroidUseAssemblyStore>
in the configuration you are using with Xamarin.UITest.
4.try to delete obj and bin folders in your app and try again.
Last last week I started having an issue with every solution I've tried to build with Visual Studio. I was using VS 2019 and our organization had just pushed down some windows updates (not sure if that's related) but after the updates I was on VS 2019 version 16.8.4, .Net version 4.8.03752.
Whenever I try to build one of our solutions (I tried 3 different solutions after doing a free pull from the main branch of our repo) I get over 1000 errors which seem to be cascade errors from the OutputPath property not being set which seems to be related to several of the projects being arbitrarily changed from Debug to Release even though the solution is set to Debug | Any CPU.
Furthermore, if I examine the build tab on the project properties (or examine them in configuration manager) NO DEBUG CONFIGURATION IS SHOWN AS AVAILABLE. If I close Visual Studio it prompts to me save changes and if I do a comparison shows that it did indeed change the configuration of several projects form Debug to Release.
I have reproduced this on 2 separate machines, with fresh installs of Visual Studio 2019 (and 2017) and pulling fresh code from the repos. Other developers in my org an build the solutions just fine and their configurations show Debug | Any CPU across the board (i.e. I seem to be the only person in the world having this problem and I'm having it on every machine I've tried and with multiple versions of Visual Studio).
I also see errors saying that projects contains nuget references that are "missing" but if I restore nuget pacakges I get a messages saying they are all installed and there is nothing to restore. I also see the "missing" packages in the packages folder.
We use relative paths for the packages so it can't be the typical literal-path issue some people have. Besides which, my folder structure hasn't changed and we all use the same folder structure in our ord.
I am completely at a loss as to what to try next. My googlefoo has completely failed me in this regard.
I'm desperately hoping someone in the Stack Exchange world can offer a solution.
Thanks,
Greg.
Please check if your project's csproj file has missed these content:
You could directly add these at the bottom of the csproj file:
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<PlatformTarget>AnyCPU</PlatformTarget>
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>bin\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<PlatformTarget>AnyCPU</PlatformTarget>
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
After that, delete bin and obj folder.
Then, run update-package -reinstall under Tools-->Options-->Nuget Package Manager--> Package Manager Console to reinstall all nuget packages.
I am at my wits end here. I have checked out a project from our repo and I get this error when building:
System.IO.DirectoryNotFoundException: 'Could not find a part of the path 'C:\DEV\myproject\BIN\DEBUG'.'
This directory exists. I am running VS as an admin. I believe this folder is just recreated when I hit build. I would provide more information if I knew what information to provide.
Where does one begin to troubleshoot this?
I came across a similar problem - could not build in Release mode, and could not publish. I fixed it by closing VS, opening the csproj file in Notepad++ (text editor) and deleting the content in <OutputPath> for the Release mode.
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<PlatformTarget>AnyCPU</PlatformTarget>
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
**<OutputPath>V:\Programs\Billable_Hours\</OutputPath>**
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
Then I opened the project in VS and re-set the Release build output path to the bin/Release folder, and everything worked perfectly.
I have a multiple-project solution and wish to put all the generated in/obj artifacts in a another folder.
I try to set:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DebugType>portable</DebugType>
<OutputPath>..\Bin\Core\Debug\</OutputPath>
<IntermediateOutputPath>..\Bin\Core\obj\</IntermediateOutputPath>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<OutputPath>..\Bin\Core\Release\</OutputPath>
<IntermediateOutputPath>..\Bin\Core\obj\</IntermediateOutputPath>
</PropertyGroup>
<ItemGroup>
<Compile Include="Library.fs" />
</ItemGroup>
</Project>
However:
The obj folder is still re-created in the original location. Is
also on the desired location but EMPTY.
The "restore packages" trigger "1" and not put them on the desired location
When the project is build, the obj folder is populated.
This is the versions:
Visual Studio Community 2017 for Mac Version 7.3.2 (build 12) Runtime:
Mono 5.4.1.7 (2017-06/e66d9abbb27) (64-bit)
NuGet Versión: 4.3.1.4445
.NET Core Runtime: /usr/local/share/dotnet/dotnet Versión de tiempo de
ejecución: 2.0.0 SDK: /usr/local/share/dotnet/sdk/2.0.0/Sdks Versión
del SDK: 2.0.0 SDK de MSBuild:
/Library/Frameworks/Mono.framework/Versions/5.4.1/lib/mono/msbuild/15.0/bin/Sdks
This problem is not specific to Visual Studio for Mac. The same behaviour occurs if you use the dotnet from the command line.
With Visual Studio for Mac, and the dotnet CLI, the obj directory gets created in the project directory on restoring the NuGet packages and contains just the files generated by the restore:
MyProject.csproj.nuget.cache
MyProject.csproj.nuget.g.targets
MyProject.csproj.nuget.g.props
project.assets.json
On building files are created in the ../Bin/Core/Debug and the ../Bin/Core/obj directories.
You can get the behaviour you want by setting the BaseIntermediateOutputPath. However setting it in the project file itself can cause problems.
The simplest solution is to create a Directory.Build.props file in the solution directory and set the BaseIntermediateOutputPath property there.
<Project>
<PropertyGroup>
<BaseIntermediateOutputPath>..\Bin\Core\obj\</BaseIntermediateOutputPath>
</PropertyGroup>
</Project>
Then the generated NuGet restore files will be created in the directory you want.
Visual Studio for Mac seems to still want to create an empty obj directory in the project when the project is opened but this has no files after the restore or build.
I'm getting an error in a VS2010 DB project that indicates I have too many charachters in my build path.
How can I change my default build path for all project types?
Something like
c:\build\$(projectname)\......
Thanks!
EDIT:
I've moved my project to the root of the C: drive and I still get the error with my DB project. I get this error when I try to right click the project and select properties
An error occurred trying to load the project properties window. Close the window and try again.
Cannot evaluate the item metadata "%(FullPath)". The item metadata "%(FullPath)" cannot be applied to the path "obj\Debug|Any CPU\TASS.DB.dbschema". Illegal characters in path. C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets
The first thing that jumps out to me here is that your platform and configuration are being fused together to form "Debug|Any CPU" and a string is being made from that--the pipe is the character it's referencing there when it says there are illegal characters. I'm not sure how much your database project really differs with respect to debug/release and for architecture, but you may not even need to include them in the path.
Since you can't open the project property pages, you'll need to edit the msbuild directly by unloading it and selecting "Edit..." from the context menu (sorry if you know this already).
From there, assuming you're realling running up on the windows path length ceiling, you could use some msbuild trickery to maximize your headroom in there. Specifically, doing something similar to what you suggest: use the C:\ drive wherever possible.
To do this, look inside the PropertyGroups with the conditions for your Configuration & Platform configurations, and inside them replace the OutputPath and IntermediateOutputPath properties so that they're as short as possible, for example:
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|AnyCPU'">
<OutputPath>$(SystemDrive)\D\A</OutputPath>
<IntermediateOutputPath>$(SystemDrive)\o\D\A</IntermediateOutputPath>
</PropertyGroup>
This saves some valuable characters in that instead of "Debug" you're using "D", "A" for "AnyCPU" and "o" for "obj".
Probably most importantly you're using C:\o\ for the intermediate build directory instead of C:\whatever-the-whole-path-is-to-your-project-file\obj. As well, this property isn't configurable from the property pages, from what I recall.
Some added flexibility there using SystemDrive instead of a hard-coded C:, not that I would really expect it to be different.
Finally, concerning your property pages load problem, I don't know how the Debug|AnyCPU got in your path (I don't know of any properties that store the concatenated flavor like that), but you should be able to pick it out pretty easily once you open up the file. Hopefully it's similar to load errors in something like the winforms designer where you change one line and suddenly the whole thing works again.
Hope this helps!
I don't think it's possible to set a default build path for all projects, only the standard Debug/Release folders within the project itself. The only suggestion I would have is to simply move the project folder to location with a shorter path.
EDIT: As per the new edit, have a look here:
http://connect.microsoft.com/VisualStudio/feedback/details/594333/database-project-template-files-corrupt
I updated a project from VS 2005 to VS 2010 and got the same error message.
"The item metadata "%(Filename)" cannot be applied to the path "obj\Debug|x86\Debug\DemoCSharp.pdb". Illegal characters in path." The problem is that Visual Studio 2010 fails in converting the csproj file to the new format, but it does not tell us where exactly the error is.
In my VS 2005 csproj file there is the following XML code:
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">Debug|x86</Platform>
<ProductVersion>8.0.50727</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>{05F88317-0CA7-4FE5-8520-35422402941A}</ProjectGuid>
<OutputType>Exe</OutputType>
<RootNamespace>DemoCSharp</RootNamespace>
<AssemblyName>DemoCSharp</AssemblyName>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>..\output32\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<DebugType>full</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
<OutputPath>..\output32\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<Optimize>true</Optimize>
<DebugType>pdbonly</DebugType>
<PlatformTarget>x86</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' ">
<DebugSymbols>true</DebugSymbols>
<OutputPath>..\output64\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<DebugType>full</DebugType>
<PlatformTarget>x64</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x64' ">
<OutputPath>..\output64\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<Optimize>true</Optimize>
<DebugType>pdbonly</DebugType>
<PlatformTarget>x64</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
</PropertyGroup>
Visual Studio does NOT tell us which line produces the problem. But I found it by "try and error".
The cause of the error message is clearly a bug in the Visual Studio conversion wizard because VS 2005 has no problem loading this csproj file while VS 2010 fails to convert it.
So you have to manually edit and fix this file and then load it anew in VS2010.
In my case the line that triggers the bug is the 3. line with <Platform Condition. The bug is that VS tries to take the value ("Debug|x86") of this platform condition XML node and embed it into a path on disk (like "...\obj\Debug|x86\..."). But as pipe characters are illegal in paths, it later complains and aborts the conversion.
So how to solve the problem ?
I simply replaced the third line
<Platform Condition=" '$(Platform)' == '' ">Debug|x86</Platform>
with
<Platform Condition=" '$(Platform)' == '' ">Debug</Platform>
which eliminates the pipe character and the project converted without errors.
NOTE: It is also possible to completely delete this line.
ATTENTION:
It is possible that in YOUR case the same error messages needs another fix than in my case. Please study the csproj file and look for the pipe characters, then find out with try and error how to modify it. This error can even appear in other conditions than converting a project.
But what they all have in common is that this is a Visual Studio bug (or in case of 'littlechris' a software extension bug) that tries to embed a pipe character into the path.
XML node: "Debug|x86" -> path "...\obj\Debug|x86\..."
I received this messeage because the absolute path of one of the files in my project exceeded 260 characters. Once I reduced the path length, I was able to build the project.