I'm using VS2013, Xamarin.Android 4.12.4.20.
Build is successful.
I'm getting error from title whenever I try to deploy in debug mode or package.
It started to happened today it work fine before.
I've restarted VS, device, PC - none helped.
Stack trace:
Xamarin.AndroidTools.AndroidDeploymentException: InternalError ---> System.ArgumentException: An item with the same key has already been added.
at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
at Mono.AndroidTools.Adb.AdbSyncDirectory.Add(AdbSyncItem entry)
at Xamarin.AndroidTools.AndroidDeploySession.InstallAssemblies(String destinationPath, CancellationToken token)
at Xamarin.AndroidTools.AndroidDeploySession.FastDev()
at Xamarin.AndroidTools.AndroidDeploySession.Run(CancellationToken token)
at Xamarin.AndroidTools.AndroidDeploySession.RunLogged(CancellationToken token)
--- End of inner exception stack trace ---
at Xamarin.AndroidTools.AndroidDeploySession.RunLogged(CancellationToken token)
at Xamarin.AndroidTools.AndroidDeploySession.Start(CancellationToken token)
Build output:
3>Build succeeded.
3>Waiting for device..
3>Detecting installed packages
3>Detecting installed packages...
3>
3>Removing previous version of application
3>Removing previous version of application...
3>
3>Installing application on device
3>Copying application to device...
3>
3>Getting installation path...
I've figured it out. Make sure that you don't have different versions of the same dll referenced!!
Let me describe my set up a bit more that will help with explaining why exception happened.
I've got two projects
Domain - library with code shared between all platforms
Android - android specific code
Both have nuget references to the same library. At some point android (only in this project) nuget references have been updated which resulted in two versions of the same library required by the application (Domain project still referenced old nuget).
When I tried to package solution I would get warning like :
Consider app.config remapping of assembly "{Library}" from Version "5.6.0.0" [] to Version "5.6.1.0" [{Path}] to solve conflict and get rid of warning.
Once I've update Domain's nuget everything worked.
Related
I'm attempting to set up this Rust template project to get started doing Rust development for ESP32: https://github.com/esp-rs/esp-idf-template
I've installed the Rustup esp toolchain, as described here: https://github.com/esp-rs/rust-build
At the Generate the Project step, I chose these parameters:
Configure project to use Dev Containers = false
ESP-IDF native build version = v4.4
Rust toolchain = esp
STD Support = true
MCU = esp32
At the Build step, I get this output (second run displayed, first run compiles a long list of dependencies before this point):
C:\Users\Me\boop\doop>cargo build
Compiling esp-idf-sys v0.31.6
error: failed to run custom build command for `esp-idf-sys v0.31.6`
Caused by:
process didn't exit successfully: `C:\Users\Me\boop\doop\target\debug\build\esp-idf-sys-cafd80a349bfdbb2\build-script-build` (exit code: 1)
--- stdout
cargo:rerun-if-env-changed=IDF_PATH
cargo:rerun-if-env-changed=ESP_IDF_TOOLS_INSTALL_DIR
cargo:rerun-if-env-changed=ESP_IDF_VERSION
cargo:rerun-if-env-changed=ESP_IDF_REPOSITORY
cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG_DEFAULTS
cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG
cargo:rerun-if-env-changed=MCU
IDF_PYTHON_ENV_PATH=C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env
PATH=C:\Users\Me\boop\doop\.embuild\espressif\tools\esp32ulp-elf\2.28.51-esp-20191205\esp32ulp-elf-binutils\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\cmake\3.23.1\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\ninja\1.10.2\;C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env\Scripts;C:\Users\Me\boop\doop\.embuild\espressif\esp-idf\release-v4.4\tools;%PATH%
Current system platform: win64
Skipping xtensa-esp32-elf#esp-2021r2-patch3-8.4.0 (already installed)
Skipping cmake#3.23.1 (already installed)
Skipping ninja#1.10.2 (already installed)
Skipping esp32ulp-elf#2.28.51-esp-20191205 (already installed)
IDF_PYTHON_ENV_PATH=C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env
PATH=C:\Users\Me\boop\doop\.embuild\espressif\tools\esp32ulp-elf\2.28.51-esp-20191205\esp32ulp-elf-binutils\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\cmake\3.23.1\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\ninja\1.10.2\;C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env\Scripts;C:\Users\Me\boop\doop\.embuild\espressif\esp-idf\release-v4.4\tools;%PATH%
--- stderr
Using managed esp-idf repository: EspIdfRemote { repo_url: None, git_ref: Branch("release/v4.4") }
fatal: No names found, cannot describe anything.
Using esp-idf v4.4.1 at 'C:\Users\Me\boop\doop\.embuild\espressif\esp-idf\release-v4.4'
fatal: No names found, cannot describe anything.
Error: Access is denied. (os error 5)
I get the same error when I choose ESP-IDF native build version = v4.3.2, although without the fatal: No names found, cannot describe anything. messages.
I get an identical error when attempting to build this Rust ESP32 demo project: https://github.com/ivmarkov/rust-esp32-std-demo
This was run as Administrator.
In my search for a solution, I found this: Why os.rename sometimes returns error access is denied python Per the top answer, I disabled "Show frequently used folders in Quick access" in File explorer, but unfortunately the build error has not changed.
What access is being denied, and what could be causing the denial, even when run as Administrator?
Secondarily, what is the cause and meaning of the fatal: No names found, cannot describe anything. messages?
I've been working through the same issue today.
It is caused by a change in the embuild dependency: https://github.com/esp-rs/embuild/commit/d8f8da228f1e1e6c105074d96617a8601092f633
Trying to write permission data to an open file causes the 'os error 5
I've submitted a PR to the project: https://github.com/esp-rs/embuild/pull/56
Now merged, cargo update and you should be good!
I'm getting the same error message as in this question: Could not load type 'Microsoft.Cct.Services.Sqm.IWatSqmService' Unfortunately, I cannot upgrade to Azure SDK 2.9, as the top answer there suggests.
Specifically, I get this error in a message box whenever I try to package my Azure Cloud Service project:
What's interesting is that I can start the same project in the emulator, which I would assume involves packaging it.
Things I've tried:
Ensuring that I only have version 2.8.2 of the emulator installed (I may have had 2.9 installed initially)
Reinstalling version 2.8.2 of the SDK
Manually copying the Windows Azure Tools from C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0 to the v14.0 equivalent.
Ensuring that C:\Program Files\Microsoft SDKs\Azure\.NET SDK\v2.8 exists
Reinstalling Visual Studio (so you know I'm desperate!)
And I've no idea what to try next. I can't work out which DLL is supposed to hold the Microsoft.VisualStudio.WindowsAzure.Services assembly, I can't find any references in any config files, and all the Google hits seem to point back to the SO question linked above.
What's going on? And how can I fix it?
In case I'm being an idiot, here's all the Azure-related things I've got installed:
Also (just in case it's relevant) I'm on Windows 7 SP1.
Update 17/01/16
Following some advice from the excellent Rest Azured Slack channel, I've tried using ProcMon and Fusion Log to diagnose this (spoiler: without success)
ProcMon filtered to that assembly returns nothing:
Fusion log (set to log everything) yields lots of entries like this:
* Assembly Binder Log Entry (17/01/2017 # 11:52:02) *
The operation was successful. Bind result: hr = 0x0. The operation
completed successfully.
Assembly manager loaded from:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll Running under
executable C:\Program Files (x86)\Microsoft Visual Studio
14.0\Common7\IDE\devenv.exe
--- A detailed error log follows.
=== Pre-bind state information === LOG: DisplayName = Microsoft.VisualStudio.WindowsAzure.Services, Version=1.1.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a (Fully-specified)
LOG: Appbase = file:///C:/Program Files (x86)/Microsoft Visual Studio
14.0/Common7/IDE/ LOG: Initial PrivatePath = NULL LOG: Dynamic Base = NULL LOG: Cache Base = NULL LOG: AppName = devenv.exe Calling assembly
: Microsoft.VisualStudio.WindowsAzure, Version=2.9.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a.
=== WRN: Native image will not be probed in LoadFrom context. Native image will only be probed in default load context, like with
Assembly.Load(). WRN: No matching native image found. LOG: IL assembly
loaded from C:\Program Files (x86)\Microsoft Visual Studio
14.0\Common7\IDE\Extensions\Microsoft\Windows Azure Tools\Microsoft.VisualStudio.WindowsAzure.Services.dll.
When I explore the DLL mentioned, I can find Microsoft.Cct.Services.Sqm, but it doesn't contain a type IWatSqlService:
This feels like it's the crux of the issue, but I've no idea what to do next. Presumably I'd need to replace the DLL with a version that does define IWatSqlService, but I'm not sure where I'd get one. Or, for that matter, why it would even be necessary.
Next stop is probably a full wipe of the machine.
I've had the same problem, and solved it by not using the Web Platform Installer.
Download all parts (Microsoft Azure SDK for .NET - 2.8.2) from the Microsoft site: https://www.microsoft.com/en-us/download/details.aspx?id=50041 and follow the instructions how to install them.
For anyone else with this problem. I ended up resolving this by nuking it from orbit. Fresh install of Windows, reinstall VS and the SDK.
Confusingly, you can also see this error when you add a new
<setting name="TODO" />
element to your *.csdef file but either:
forget to add the corresponding <setting name="TODO" value="TODO" /> element to every *.cscfg file, or
accidentally add a duplicate <setting name="TODO" value="TODO" /> element to any of the *.cscfg files.
I have quite a complex TeamCity-Solution.
Configuration "tcBuild" builds and creates nuget-packages, as well as it modifies the version number of the assembly.
Configuration "tcDeploy" depends on "tcBuild", takes the nuget-packages and send it using octopus.
tcBuild just works fine and also creates the wanted packages.
tcDeploy throws the following error for each package:
2014-01-28 14:50:05.5826 ERROR Unable to download package:
Octopus.Platform.Deployment.ControlledFailureException: Could not find package Packagename 1.1.0.903 in feed: 'http://localhost/httpAuth/app/nuget/v1/FeedService.svc/'
at Octopus.Shared.Packages.PackageDownloader.FindPackage(Int32 attempt, PackageMetadata packageMetadata, IFeed feed, IActivity log) in c:\TeamCity\buildAgent\work\1116bd9da9e239fd\source\Octopus.Shared\Packages\PackageDownloader.cs:line 155
at Octopus.Shared.Packages.PackageDownloader.AttemptToFindAndDownloadPackage(Int32 attempt, PackageMetadata packageMetadata, IFeed feed, IActivity log, String cacheDirectory, IPackage& downloadedPackage, String& path) in c:\TeamCity\buildAgent\work\1116bd9da9e239fd\source\Octopus.Shared\Packages\PackageDownloader.cs:line 130
at Octopus.Shared.Packages.PackageDownloader.AttemptToDownload(PackageMetadata metadata, IFeed feed, IActivity log) in c:\TeamCity\buildAgent\work\1116bd9da9e239fd\source\Octopus.Shared\Packages\PackageDownloader.cs:line 89
2014-01-28 14:50:05.5826 ERROR Error in DownloadAndPushToTentaclesOrchestrator-OCw-lDdz+eWP#SQ-PESY0002-F9FA8F1A while receiving bedf70c1-1f30-496f-91ca-aba6cc956042
(where "packagename" is the name of the package)
The version number of the error message is the same as of the nuget packages' "core-properties"-folder.
Other, quite similar builds on that machine work just fine. Tell me if I need to provide more information.
You can try to create one tc project to package which triggers another project to deploy. We ended up with this approach so that we can deploy the latest build to octopus. Good luck.
I'm new to Xamarin Studio and mdtool so apologies for the noob question but I'm completely stuck on this and my Google searches aren't finding the answer to my problem.
Basically our solution builds perfectly in Xamarin Studio and now I need to run it from the command line so I can put it into our standard buildsystem but I appear to have missed something in the setup or configuration as it complains about the fact that it cannot find a registered GTK# installation.
I have installed Mono for windows 2.10.9 which contains GTK# 2.12.11 but I have also installed the standalone GTK# 2.12.20 because our developer says he has that installed and it is all installed on Windows Server 2012 in a VM at the moment while I test it all.
Here is the command I'm running to get it built and the eror that it responds with:
mdtool build '--configuration:Release' test_mono.sln
ERROR [2013-05-24 15:56:25Z]: Did not find registered GTK# installation
MonoDevelop Build Tool
System.TypeInitializationException: The type initializer for 'Mono.Unix.Native.Stdlib' threw an exception. ---> System.BadImageFormatException: An attempt was made to load a program with an incorrect
format. (Exception from HRESULT: 0x8007000B)
at Mono.Unix.Native.Stdlib.GetDefaultSignal()
at Mono.Unix.Native.Stdlib..cctor()
--- End of inner exception stack trace ---
at Mono.Unix.Native.Stdlib.free(IntPtr ptr)
at Mono.Unix.Catalog.MarshalStrings(String s1, IntPtr& p1, String s2, IntPtr& p2, String s3, IntPtr& p3)
at Mono.Unix.Catalog.Init(String package, String localedir)
at MonoDevelop.Core.GettextCatalog..cctor()
The type initializer for 'Mono.Unix.Native.Stdlib' threw an exception.
Any ideas what I've done wrong or overlooked?
I am using Marmalade to build a PlayBook app, but I think my question applies to PlayBook apps in general. I have successfully created a debugtoken.bar file and have installed it on my device. When I go to try to install a built application.bar file on the device, I get:
[execute] "blackberry-deploy.bat -device 192.168.1.114 -password ******* -installApp -package deployments\default\playbook\release\Quote Unquote.bar"
Info: Sending request: Install
Info: Action: Install
Info: File size: 6400334
Info: Installing ...
Info: Processing 6400334 bytes
actual_dname::
actual_id::
actual_version::
result::failure 881 required signatures missing (RDK, AUTHOR)
ERROR: error running blackberry-deploy
***ERROR***
Note that this is the Marmalade deploy tool running the standard PlayBook installer.
What I don't understand is: I thought the point of using a debugtoken.bar file was that you could install unsigned apps. I have in fact successfully deployed these unsigned apps using the Marmalade deploy tool just like this. But I was having problems signing the app for distribution, so I went back and did everything from scratch, requested new code signing keys from RIM, made a new debugtoken.bar file and installed it, etc. And now I'm worse off than I was before because I can't even install to the device now.
So again: My understanding is that the point of debugtoken.bar was to be able to deploy to the device before actually signing the application.bar for distribution. So what does this error message even mean?
To answer my own question:
For deploying a "debug" build to a device, it's critical to have
Application-Development-Mode: true
in the MANIFEST.MF within the .bar file.
A stupid mistake, but I'll leave this up in case it helps anyone...
Taking a look to the QNX deployment plugin "C:\Marmalade\6.1\s3e\deploy\plugins\qnx\qnx.py" I found that 'FOR DEVELOPMENT' option is false if the 'playbook_keystore' is given so I just cleared the signing section on the Marmalade System Deployment Tool and it is not longer trying to sign it