When I launch UWP project, it crashes and I'm getting errors like these.
And this error occurs mostly when its on debugging mode.
Soo.. first idea for fixing this was upgrading/downgrading nuggets, but that didn't help me, also I have these nuggets included for UWP:
Microsoft.NETCore.UniversalWindowsPlatform
SQLite.Net-PCL
System.Data.SQLite
Xamarin.Forms
XLabs.Forms
etc other(that dosent matter on this exception)
I also looked other posts for solving this, like adding SQLite extension, but I didnt find the extension from Universal Windows->Extensions.
Im pretty stuck with this problem, I think its probably a problem with nuggets
You were fairly close. Go to Tools > Extensions and Updates. Click the Online tab in the left hand menu.
Search for SQLite and download SQLite for Universal Windows Platform.
Now go back to the Extensions window, as you showed above, and tick the SQLite for Universal Windows Platform. Ensure you keep the Visual C++ 2015 Runtime ticked, you need this as well.
I have a Xamarin Android app that we've been using for years now. Recently, we started seeing a problem where we can't trace into or set breakpoints in certain methods/classes. If I set a breakpoint, it doesn't stop at it and if I try to trace into it, it goes to a completely different area of the code. This may be related to the fact that we recently had to enable Multi-Dex support, but I'm not sure if that is related. I have several developer seeing the same problem. We are using Visual Studio 2015.
I noticed that if I set the linker option to "Sdk and User assemblies", my debugging problems go away. however, I then see crashes because it appears the linker is removing methods that are needed.
I'm wondering if there are any workarounds for this issue, as I am plagued by frequent crashes -- though it isn't clear whether the crashes are caused by Resharper, Xamarin Tools or the mixture of C# and F# projects.
When I restart Visual Studio and load a solution containing Xamarin Forms projects, the entire display locks up. After one to three minutes, I get a pop-up saying that an update for Xamarin for Visual Studio is available (Clicking on the pop-up has no effect, so I'm assuming this is a false positive). A few seconds after that, it attempts to connect to my Mac, which is often unsuccessful as I work on my laptop and that connection is only available when I'm at home.
Only when the connection to the Mac has failed am I able to interact with Visual Studio, and then, about 30% of the time, attempting to build, clean or rebulid simply results in a pop-up saying "The operation could not be completed". The only way to fix that is to restart Visual Studio, causing the whole grinding process to restart again.
Xamarin themselves have referred me to these forums. Obviously this is not a pure software question, so I'll try to distill this into specific answerable questions.
Is there a way to prevent the false positive that tells me a new version of Xamarin for Visual Studio is available when it clearly isn't?
Is there a setting that I can use in order to opt in to connecting to the Mac, rather than attempting to make a connection and killing startup time when I know in advance that the connection will not be made?
Has the build problem "This operation could not be completed" been reported anywhere? I haven't found any instances of this problem related to Xamarin or Resharper. But it is frequent.
Does this consistently happen? We've had this problem over the years, but it's gotten much better. Make sure all your machines are synced with the latest Stable update. If on Beta/Alpha, this is typical as we push builds often. The strange part is that you say it's trying to update Xamarin Studio, we actually don't ship Xamarin Studio for Windows anymore: https://www.xamarin.com/faq#xpq6. So it might be a good idea to uninstall a previous version of Xamarin Studio on Windows if it's there.
This is a good point. It's something that might need a small papercut bug filed. Feel free to log an issue here and I can coordinate the status: (https://bugzilla.xamarin.com/enter_bug.cgi?product=Visual%20Studio%20Extensions). In the past I've seen a couple ways around this. 1) Make a seperate .sln that might be called .Windows which will only load Windows native projects (Android, UWP, etc). This way the step is skipped completely. 2) You can simply unload the iOS project until you need to reload the project and work on the iOS side. However I do agree there should be a project property/IDE setting that should say "Start Xamarin Mac Agent on Startup".
That error is really vague. We would need to gather some logs(log files can be gathered from %LOCALAPPDATA%\Xamarin\Log or using Help->Xamarin). This operation could not be completed typically has an error/exception following it like This operation could not be completed: Invalid Pointer. So we would need to dig into logs here and see if we can get a Stack Trace when it happens. I would also try deleting your .suo in the .vs hidden folder of your project directory.
I have a Xamarin.Forms Android app that I have been developing in Visual Studio 2015 for several months.
Until today, I have been able to reliably debug the app in both the Android emulator and on a physical device. Now, suddenly, debugging the app in either of these environments results in numerous exceptions.
For example, during its startup sequence, my app initializes Xamarin Insights:
Insights.Initialize(apiKey, Forms.Context);
This has been working fine for months, but now it throws the following exception:
Java.Lang.SecurityException: ConnectivityService: Neither user 10133 nor current process has android.permission.ACCESS_NETWORK_STATE.
I can work around this exception, either by commenting the above code line or by explicitly assigning permission ACCESS_NETWORK_STATE, but it wasn't necessary previously and I believe it is a red hering, since it is one of numerous new random exceptions that occur when debugging the app in Visual Studio.
I have reverted my codebase to a known working revision (one that is being successfully used by beta testers) and nothing changes.
I have tried restarting Visual Studio and rebooting the computer. I have also tried cleaning the solution (both from within Visual Studio and by physically removing all build artefacts) but none of these efforts have helped.
I am guessing that something has been corrupted in Visual Studio, but in view of the time it takes to reinstall, I am hoping that someone may have a suggestion for a quicker fix.
As you said that it works well if you add the "uses-permission" in the Mainfest, if so, do you debug your app in release mode or debug mode?
Like this document here:
https://developer.xamarin.com/guides/android/advanced_topics/working_with_androidmanifest.xml/
In the Release build version of the manifest (at obj/Debug/android/AndroidManifest.xml), these permissions are not automatically configured. You could add it from the project property.
I really like the idea of working with Visual Studio, C# and Unity on OS X.
Has anyone made debugging with C# in Unity work with Visual Studio Code on OS X?
Yes it works absolutely fine. Unity is C#, JavaScript or Boo. So, you don't need .NET for it. Unity uses Mono runtime. So, an existing VS project can be opened in Unity for Mac OS X.
EDIT
Here is a link that helps you to attach a debugger to the VS endpoint.
http://www.yunspace.com/2015/01/19/integrating-visualstudio-with-unity3d-on-mac-using-vstools/
You can try VS Tools for Unity too.
http://unityvs.com
UPDATE
There is this awesome Unity Plugin by dotBunny that solves the problem and integrates Code with Unity tools.
Hi the solution is https://github.com/dotBunny/VSCode This plugin works on both MacOS and Windows and gives you the following capabilities:
•An option to enable VS Code integration (Editor –> Assets –> Enable Integration), this updates your solution files and (more importantly) keeps them in sync. This also sets the preferred external tool editor in the Unity preferences.
*Note, the old “Sync MonoDevelop” option is now gone in the Unity editor from V5.2
•It writes out the necessary (and sometimes hard to find) VS Code configuration files, including the ability to hide “non-code” files in the editor (hides things like .sln, .csproj and the ever present unity .meta files)
There are a couple of other settings in there to help speed up the integration.
•Automatically launches VS Code direct to your project folder, EVERY-TIME. no longer do you have to worry about keeping that window open, or switching around if you work on multiple projects
One thing to be aware of, once you enable the VSCode integration, changing your preferred code editor in the External Tools preferences will have no effect as the plugin takes over opening code files. If you want to use another editor, you’ll have to disable the integration first.
These are just the main highlights as there are more features in there as well.
Currently you need to download the plugin files from GitHub
An existing Visual Studio solution can be build and debugged with Visual Studio Code on the Mac with Mono. You have to use the launch.json and tasks.json files.
I described it on my blog: Compile and Debug
To build Unity in Visual Studio Code, you can hook up Mono xbuild compiler as a task runner, so you don't even have to leave IDE to have errors and warnings.
See https://twitter.com/_eppz/status/846859856787259392 for more.
It's a little unstable. But it's possible from recent VSC version.
1) Install this VSC Unity plugin-in.
https://github.com/dotBunny/VSCode/
2) Follow these commands. (Step 1, 2 and 3)
https://code.visualstudio.com/Docs/runtimes/unity
3) After you complete the settings, launch the VSC using Unity menu.
Assets/Open C# Project in Code
4) Play the Unity project.
You can see the debug port number on the unity console.
And the project's launch.json file will be renewed automatically.
To open launch.json, click option icons.
the file exists in this folder.
.vscode/launch.json
sample.
{
"version":"0.1.0",
"configurations":[
{
"name":"Unity",
"type":"mono",
"address":"localhost",
"port":56621
}
]
}
5) Start debug in VSC debug tab.
That's it. Hope this help.
Update, 2016 - the petition was popular enough that some VS Code extensions have been written for it: https://marketplace.visualstudio.com/search?term=unity&target=VSCode&sortBy=Relevance
Petition for it on the Visual Studio UserVoice page: http://visualstudio.uservoice.com/forums/293070-visual-studio-code/suggestions/7752702-unity-integration
[Feb 2017] It is now possible to do this without the dotBunny plugin.
i.e. Support is built into Unity natively.
Just to repeat, you don't need to fiddle with Unity, just VSCode.
Instructions here
Instructions are incomplete though, and I didn't take screenshots (please do!), but basically what I did was:
(...and please improve these instructions as you go, I'm working from memory...)
I deleted/renamed my .vscode/Launch.json file, as per the link.
Double-click on some file to bring up the project in VSCode (maybe first make sure that in Unity's settings you have selected VSCode as your default code editor)
clicking the bug icon then the cogwheel, as per the link.
I had to install that vscode-unity-debug plugin in VSCode, just filtering the search with 'unity' found it.
I then had to press the green 'play' triangle.
I set a breakpoint in my code.
Now over to unity and press play, and the breakpoint gets hit.
The Unity Debugger for Visual Studio Code is working, but doesn't work well enough when doing any kind of serious work for now. I really hope they will improve it in the future as I prefer VS Code over VS.
Current problems I encountered
-Sometimes I cannot step in a function, the debugger will hang until you detach
-no local variable, you have to watch everything
-some more complex variable have no support, so you can't see what is inside
-A bit overall unstable with unexpected behaviours.
What I love about it,
Attaching & Detaching is a breeze. Just press a button, allowing to attach and detach quickly as needed. e.g. At the beginning of the program I work on, there will be an bunch of exception. I can detach and attach quickly to skip the exceptions.
The problems with it are too constraining as it currently stands, I had to go back to the classic Visual Studio.