I have recently started getting the error ResolveLibraryProjectImports: PathTooLongException on my xamarin android project within xamarin.forms. When I look up online all solutions say to relocate the project. Is there any way to change the project properties or a way to remap that can help me avoid relocating the entire project?
Update:
Due the the bounty and since the question has come up below, here is why I am looking for an alternate solution to relocating:
Directory hierarchies are there for a reason. If not everyone would have the whole bunch of folders the root. They are designed to allow us to organize everything. Same is my case. I have organized all folders based cloud, codes, frameworks etc. Of all the frameworks I have worked with, I have never had relocate a project because of an internal requirement of the project. So, I do not see a reason I need to move a project out of all these folders (which also means out of cloud) and throw them in some location apart from the rest of the projects, just because the project asks for it.
I faced the same Issue before, here is what I have found :
Windows has a Maximum Path Length Limitation. You could see it in Windows Naming Files, Paths, and Namespaces :
Maximum Path Length Limitation In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is "D:\some 256-character path string" where "" represents the invisible terminating null character for the current system codepage. (The characters < > are used here for visual clarity and cannot be part of a valid path string.) This is the reason why you have the issue.
You could shorten the directory path to your project to solve this problem, another solution is use the long path tool. But as PierceBoggan said :
the easiest way to avoid this issue is to move your source to the C:/ drive (or another location with fewer characters in the path).
Update :
The issue was fixed in Xamarin.Android 8.0.2.1, and this version is included in the Visual Studio 2017 version 15.4.2 release. You could read this document :
https://developer.xamarin.com/releases/android/xamarin.android_8/xamarin.android_8.0/#Issues_Fixed
I faced this issue too. Updating VS 2017 to 15.4.0 fixed it for me. Moving it closer to C:\ didn't change anything.
I had this problem even when moving my project to root of drive. However after updating Visual Studio to the newest version(15.7.0) the option to change archive output directory has been added to IDE:
Tools --> Options--> Android Settings : Archives Location
By setting this location to a directory as close to drive root as possible(such as D:\Archives), this error will go away.
Literally every new Xamarin Forms project that I try and build hits the MAXPATH error on the Android project the first time (because my default Projects Github folder path is already long).
I have a simple and routine fix that for me works for me 100% of the time because the culprit in my case is the intermediate or [obj] folder.
Try this: Open the .csproj file in notepad. Make sure it's the .csproj for the Android project. Under the first <PropertyGroup> tag add this element:
`<BaseIntermediateOutputPath>C:/Intermediate/Android/YourProjectName</BaseIntermediateOutputPath>`
Now just reload the project and try building again. Hope this helps!
Related
This has been killing me for the last couple of days. I have read everything I can find on this error and have done what xamarin says but it still doesn't work.
I can't get my builds to get through azure pipeline xamarin.ios build and deploy to apple.
When I build locally I get messages like
MTOUCH : warning MT1502: One or more reference(s) to type 'UIKit.UIWebView' already exists inside 'Xamarin.Forms.Platform.iOS, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null' before linking
with a companion message that says no references after linking
when I use --warn-on-type-ref=UIKit.UIWebView with the optimize arg.
When I build on azure in my pipeline, I only see the MT1502 but nothing saying anything after linking. The build gets submitted to Apple and fails because of the ITMS message.
I don't know what to do. I am using the latest macOS vm image, mono 6.8.0.123, xamarin.ios 13.16.0.13, xcode 11.4.1. The pipeline worked fine before April 30 deadline, now no matter what, I can't get the linker to strip UIWebView.
Let me know what other info would be helpful. I am completely stuck at this point.
Thanks.
I just got my build to pass Apple's inspection.
What ended up working for me was building locally and packaging the ipa file. On my mac I then changed the ipa extension to zip and unzipped it. I used terminal to go to the YOURAPPNAME.app "folder" and used grep -r UIWebView . to search for references. Don't forget the . so it searches the current directory. I missed that at first and got some message that grep was listening on stdin.
For me that resulted in a line like this:
Binary file ./Frameworks/PersonalizedAdConsent.framework/PersonalizedAdConsent matches
Now, the important thing to note is the linker never warned about this, so I was completely unaware of it. In my case it was part of Firebase/Admob. I was only one release behind and updating to the latest fixed my problem.
I still am using --optimize=force-rejected-types-removal --warn-on-type-ref=UIKit.UIWebView -warnaserror:1503 as my mtouch args. But builds now get through.
I hope this helps point you guys in the right direction, I've spent the last 3 days just trying to get builds to upload reading every post I could find on the web on this problem.
Solved !! I had to update the way how nugets are included to the iOS project .csproj file. The problem was that linker despite the --optimize=force-rejected-types-removal flag was not removing the UIWebView component form Xamarin.Forms 4.6 probably because it did not see it.
My project was created over two years ago and I was still using the packages.config file. After the update the flag started to work and grep query returned 0 :). The best way is to compare the old .csproj file with freshly created iOS project .csproj file and see how VS is referencing nugets.
I'm trying to download and run working branch onto a second machine from Azure DevOps (formerly VisualStudio.com).
Main machine (VS2017 Pro):
SolutionABC builds and runs perfectly
Branched to SolutionABC-Branch with small changes (external to this issue)
SolutionABC-Branch builds and runs perfectly
SolutionABC-Branch checked in
Second machine (VS2019 Pro):
SolutionABC downloads, builds and runs perfectly
SolutionABC-Branch downloads, but won't build:
Tracing the errors back through the Errors dialog, I get this:
Warning BC40056
Namespace or type specified in the Imports
'Microsoft.IdentityModel.Clients.ActiveDirectory' doesn't contain any
public member or cannot be found. Make sure the namespace or the type
is defined and contains at least one public member. Make sure the
imported element name doesn't use any aliases.
A quick Google search leads me here, so following the instructions there are indeed some issues:
Firstly, how can I solve this please?
Secondly, how does this happen when the parent solution from which this is branched runs perfectly on this machine?
Update
It appears that many of the project references (both to other projects in the solution, and also to Microsoft DLL's) are also missing. Through desperation I xcopied the Microsoft DLL's from the initial project to the branched project. This has fixed the issue, but my questions are still unanswered...
Solution
The problem turned out to be the file/path length limitation of VSTS/TFS. Relocating my local repo to a shorter directory name (e.g. C:\TFS) fixed the issue.
Missing DLL files in \bin folder after downloading fully-working solution to a second machine
AFAIK, this issue should not related to TFS/Azure Devops, it is more related to the small changes or the environment settings. Although you think it is (outside the current issue), it may cause the this issue to arise where you can't see/think it.
To resolved this issue, we need to troubleshooting it:
Since the parent solution from which this is branched runs perfectly on the Second machine (VS2019 Pro), we could create a new branch without that small changes, then check if still have this issue?
Then, add those changes and check if you have this issue again.
Note: Try to remove the references from the SolutionABC-Branch solution on the second machine and add them back to check if this issue has been resolved.
Hope this helps.
How to solve this:
Use the nuget package for the Microsoft.IdentityModel.Clients.ActiveDirectory
What is causing this:
I would bet that this is pointing out a discrepancy between those two machines. Look in the directory on box 1 listed in the properties of the reference and check that the assembly is there. Verify it is in the same path on box 2. Also check the GAC on both machines. VS/MSBuild tries to be as smart as possible when looking for those assemblies and if the hint path says one thing, and it isn't found there, but the assembly is registered, the build will go through fine.
I'm trying to publish files that are unrelated to the solution as part of a one-click publish job.
This would be relatively standard, similar to what is outlined here and here too.
However, the files themselves need to reside one folder above the actual root of the website.
If I try to specify a relative path outside of the website directory, such as <DestinationRelativePath>..\Data\%(RecursiveDir)%(Filename)%(Extension)</DestinationRelativePath> this just results in the publish skipping the item, since it claims it is up to date (in reality there isn't anything there so it can't be up to date).
I've had a quick look and can't find a way to specify an absolute path, is this something that would be possible, or is there a better approach to take here?
As part of the properties of the file you want to copy you can set it to be "Copy Always" this could resolve the issue if it is just a date issue.
I'm trying to add ParseKit to a new command line project in Xcode, but the framework shows as red in the Project Navigator. When I try to build, I get this error
error: /Users/acdlite/Xcode/Chemistry Parser/../parsekit-trunk/build/Debug/ParseKit.framework: No such file or directory
I've followed the directions given by the developer in this answer: How to embed ParseKit as a private framework in a Mac App bundle.
To my knowledge, red indicates that the file is not at the specified location. The file inspector says it should be located at /parsekit-trunk/build/Debug/ParseKit.framework, which actually doesn't exist if I try to navigate there in the Finder. So then where is it located? I have no idea.
I've followed all the steps from scratch like a dozen times now, including checking out the code via SVN. It's driving me crazy, and I feel like an idiot. I wish I could be more specific but I am truly lost as to where to go from here.
Alright, after at least 20 attempts I eventually got it working. Mostly, I followed the steps given by the developer in this answer: How to embed ParseKit as a private framework in a Mac App bundle
However, following the steps exactly didn't work. For the life of me, I couldn't get the ParseKit framework to show up as an option when I attempted to add it as a dependency of my Target. Xcode would just say "No filter results found." So I skipped that step. I also did not add a "Copy Files" build phase. Doing so resulted in a dependency error.
This was way harder than it should have been, and I don't know if that's because I'm stupid or Xcode is poorly designed. Probably a combination of both.
By the way, I'm using Xcode version 4.6.1 (4H512).
Working with a website (as opposed to a web application) in VS2010 so there is no csproj file. Right-clicking on the "Site" node in Solution Explorer and choosing "Property Pages" brings up a dialog with References, Build, Accessibility, Start Options, MSBuild Options and Silverlight Applications. You can make changes in these pages, close Visual Studio, turn off the computer, go home, spend quality time with your family, get a good night's sleep, return to work the next morning, turn your computer on, make a coffee, shoot the breeze about last night's episode of Fringe, log in, start up Visual Studio, open that website, and PRESTO! Most of those settings are still there.
This, despite the fact that there is no trace of those settings anywhere outside the hallowed pixels of the dialog box itself. Certainly not in any files in the website folder. Not in the solution file, for solution file there is none. A slightly desperate search of the Registry found nothing. Where are these settings being persisted? Are they stored in the cloud? Written into the gaps between bytes in the NTFS file system? Perhaps sent over TCP port 666 into the far-flung reaches of Hell itself, to be scratched with hot, rusty nails into the tortured flesh of the eternally-damned by impassive demons with dead, black eyes.
Any advice much appreciated.
There is an SLN file, just not where you expected it. For Web Site projects they are created in your default Projects location e.g. C:\Users\username\Documents\Visual Studio 2010\Projects\YourWebSite\YourWebSite.sln (or wherever you have your default Projects location set up in Tools/Options/Projects and Solutions).
Great aren't they these website projects? What an awesome idea they were.
I just ran into this and found none of the answers given here were correct for references. These were stored using .dll.refresh files - which we can add to source control.
Ref. question here: What is a dll.refresh file in ASP.Net?
They're stored in the solution file.
The references are stored in Web.config and the Bin\ folder.
The settings get saved to the the solution and project files (.sln, .csproj). If you open the file(s) in Notepad, you'll see the various settings listed in XML format. Some settings might be stored in the user settings file (.csproj.user), like certain debugging options, etc.
EDIT
In your case, since this is a web site project, disregard the parts of my answer referring to the project file. I'm going to leave it in there though, just in case it can be useful to someone else in the future.