Yesterday I upgraded to Xamarin.Android 7.3.0, and now none of my breakpoints get hit. I've tried many things to try to get breakpoints to work again, but no luck:
Cleaning the solution
Deleting the bin / obj folders
Closing and reopening Xamarin Studio
Restarting my Mac
Creating a new Android project
Rolling back to Xamarin.Android 7.2, Xamarin.Mac 3.2, and Xamarin Studio 6.2.1.
It doesn't make sense to me that even after creating a brand new project and running it with rolled back Xamarin versions, it still doesn't work. This should eliminate it being the code, and eliminate it being the Xamarin update, and yet it still doesn't work.
The pdb files are generated, so that's something. I have my configuration set to Debug-Dev, this has Debug Information set to Full, and Define Symbols set to:
DEBUG;__ANDROID__
I'm not sure what else to try at this point, help would be appreciated!
This seems to be a bug a bug related to mono 5.0 upgrade. Solution from Bugzilla
Alternate possible temporary workaround for users who have hit this issue after updating (as opposed to a fresh install on a new machine)
(For users who might wish to continue to use Xamarin Studio 6.3 for a little while before transitioning completely to Visual Studio for Mac.)
Set "Project > Active Runtime" to "Mono 4.8.0 (8f6d0f6) (/Library/Frameworks/Mono.framework/Versions/4.8.0)".
Rebuild the Android app project.
Explanation
By default the Mono 5.0 installer will leave the Mono 4.8 tools installed alongside the new Mono 5.0 tools. When the Xamarin.Android build process runs under Mono 4.8, it will generate the old .mdb debugger symbol file format for user assemblies, so the Xamarin Studio debugger will be able to use those symbols. Do note though that the framework debugger symbols files for Xamarin.Android are all shipped as portable .pdb files starting with Xamarin.Android 7.3, so stepping into framework code (as opposed to user code) still would not work as expected.
I had this problem for months, the root folder where I had all my projects had a "#" , I renamed it and now the break points are working just fine.
Related
I use Clang 6.0.0 (from the latest build of the Windows installer) with Visual Studio 2017 to build my project, and everything works fine except for one thing, it rebuilds every file every single time. Not only that, it even recompiles everything when no code changed at all and I merely use "Start Debugging" or "Start Without Debugging"! The .obj files are still there, but it doesn't seem to be reusing them, which of course is prohibitively slow!
This happens only when using Clang 6 with "LLVM-vs2014" set in my project, when I switch "Visual Studio 2017 (v141)" or "Visual Studio 2017 - Clang with Microsoft CodeGen (v141_clang_c2)" I don't have that problem, it only compiles what changed.
What could possibly cause this behaviour?
Edit: Maybe that's what the website means by "A 64-bit version is also available, but it doesn't integrate as well with Visual Studio."
You can use fafnir.
https://github.com/kazatsuyu/fafnir
Visual Studio manages build dependencies using .tlog file, but it appears to generate wrong dependencies for recent clang. To fix it, fafnir uses API hooking to SetFileInformationByHandle through DLL injection.
Usage
Download the latest version from the release page on GitHub
Unzip it
Run install.bat
Specify the path of the directory of LLVM/clang
Specify new_toolset_name (in the form of v[0-9]+_clang_.*)
References
(Written in Japanese) Visual Studioでも最新のClangを使えるようにしたらキャッシュされていなかった
(Written in Japanese) Visual Studioでも最新のClangが使いたい！
I have a project I've been messing with and adding features to, and it was aspnet core 1.1. I am migrating it to 2.0.
I use Visual Studio for Mac, and it's up-to-date.
I am following this documentation:
https://learn.microsoft.com/en-us/aspnet/core/migration/1x-to-2x/
The exact error I'm getting is:
The predefined type `System.Object' is not defined or imported
I found the answer:
In VS for Mac, it didn't let me get to a menu for selecting the target framework for a project. This is usually opened by right-clicking the project, and selecting "properties."
VS for Mac didn't show this.
Upon using my windows install on my iMac, I found the menu and saw AspNetCore2.0 wasn't listed (but 1.0 and 1.1 were). There was also another option to install more. this led me to:
https://www.microsoft.com/net/targeting?utm_source=getdotnetsdk&utm_medium=referral
At this page, there are SDK's for the AspNet Core 2.0 for macOS and windows 64-bit. You need to install these, and then it'll build.
The fact that visual studio doesn't indicate that you're missing a selected framework for the project you're trying to build (as defined in its config file) is absurd. They need to fix this to avoid these kind of headaches. I was under the impression that it wasn't needed, as the NUGET package for 2.0 had all o this.
Using VisualStudio 2015 update 2 for a Xamarin app solution with Xamarin.Forms (PCL), Xamarin.Android, and Xamarin.iOS projects.
After upgrading Xamarin.Forms from 2.1.0.6529 to 2.2.0.31 today, debug builds of the Xamarin.Android app within VisualStudio started consistently failing with the following message:
Xamarin.Android.Common.targets(1853,3): error XA5213: java.lang.OutOfMemoryError. Consider increasing the value of $(JavaMaximumHeapSize). Java ran out of memory while executing 'java.exe -jar
I am certainly open to the suggestion to increase $(JavaMaximumHeapSize), and it looks like an MSBuild property by the $() syntax, but I'm not certain where I would set this.
How or where is the JavaMaximumHeapSize specified for Xamarin.Android builds in Visual Studio?
Found this thread on Xamarin Forums that indicates the JavaMaximumHeapSize property can be added to the Xamarin.Android project's csproj file.
Looked at the csproj file with text editor, and found the JavaMaximumHeapSize element already existed in the first PropertyGroup, but there was no value in the element.
So I put 1G in as a value, and the Xamarin.Android project began building successfully once again:
<JavaMaximumHeapSize>1G</JavaMaximumHeapSize>
Hope this saves someone else a bit of searching.
Yep it worked for me also. One of my projects already had the stub while the other didn't at all.
I tried putting the limit up to 10G but that seems to struggle and wouldn't build so I changed it back to the 1G as shown.
I have a Xamarin.Forms project, and it worked just fine until I updated my Xamarin Studio Community to latest 5.10.3 (build 51) and updated Xamarin.Forms to 2.2.0.31
When I compile my android project, it showed me
"mynamespace.Droid.Resource.Attribute" does not contain a definition for "actionBarSize"
I did not change anything after upgrade and it works before, I know some others faced the same problem like me when I search on google, seems no one asked this in stackoverflow yet so I would like to get some help here.
If the above doesn't work try this
1) Delete Bin and Obj folders in project folder
2) Delete contents of C:\Users{your username}\AppData\Local\Xamarin\zips
3) Rebuild project
*This will take a while because xamarin will re-download the required files. it should work after its done.
That's a bug listed here. There are different workarounds about this, please try:
Failed to use Android Support Library v4
Creating a Hello World in Visual Studio with Xamarin Forms Fails
Xamarin cross-platform (portable class) project compilation error
When I change the target framework of any project in Visual Studio 2010 it does not actually change the System assembly references. For example if I target v2.0 and check the properties of System and System.Data I can see that they are still both v4.0. If i change the target to v3.5, System stays at v4.0 but System.Core changes to v3.5.
Because of this I am truly not targeting anything except v4.0.
There may be something strange in your install. I just created a WPF project, keeping the default settings, thus targeting .NET 4. Then, I switched to 3.5. VS asked to reload the project and then the targeted runtime of the references was v2 (correct) and their version was 3.5 (with an error that Microsoft.CSharp and System.Xaml were missing, which is understandable).
Then, I did the same for .NET 3 and 2 and got the same results: after reloading the project, the version of the referenced DLLs had changed were it made sense (System.Data is always v2.0).
When using the CLR v2, the vshost debug helper had its name changed to something like vshost-clrv2.
I've reinstalled Visual Studio several times and it hasn't solved anything. After uninstalling there is 10.0 stuff laying all over the place leading me to believe the uninstaller is also leaving what ever is causing this issue. I'm going to have to reinstall the OS to get the issue to go away.
I also wanted to link to my earlier post because this post has more information about how I originally discovered this issue, contains a link to the Microsoft Connect bug report I opened and links to several other users experiencing the same problem: Visual Studio 2010 Can no longer build .NET v3.5