text:
ROS almost works now, but not quite...

The Robot Operating System almost works now with latest windows insider build 10.00.14965.1001, so I can get past the RAW socket problem, yay.  But ROS nodes are not talking to each other for some reason.  There is a tool called "roswtf" (yeah, that's the real name :-) which reports an interesting error:
ERROR Local network configuration is invalid: Local hostname [CLOVETT13] resolves to [2001:4898:d8:47:f136:8c9c:2110:ce3f], which does not appear to be a local IP address ['10.137.62.126', '127.0.0.1', '10.0.0.228'].
It should not report any errors.  Perhaps this is why the ros nodes are not yet talking.
I'm on Windows build 10.00.14965.1001, 64-bit.
Steps to repo:
sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main" > /etc/apt/sources.list.d/ros-latest.list'
sudo apt-key adv --keyserver hkp://ha.pool.sks-keyservers.net --recv-key 0xB01FA116
sudo apt-get update
sudo apt-get -y install ros-indigo-desktop-full
sudo rosdep init
rosdep update
roswtf
Email me at clovett at microsoft.com to get the strace, it is rather large.

Seems like a problem related to ipv6? Have you tried disabling ipv6 in windows to verify?
Running ROS would really be a step forward.

Well disabling it from the adapter settings didn't help.  ipconfig shows no ipv6 addresses, but I get the same error.  Might have to disable ipv6 more deeply somehow... but windows warns against doing that, I suspect a bunch of things may break...

I'd guess, the problem is that your ipv6 address is still cached on the dns-server and/or the local cache..

Related: 1391?

@lovettchris: unless things have changed very recently, even with roswtf completely happy, there appear to still be some unresolved issues in the network stack on WSL that prevent pub/sub to work reliably in both directions. User experience with ROS on WSL has improved a lot over the past few months though (see Installing ROS on Ubuntu Bash in Windows 10 on ROS Answers fi).

@gavanderhoorn - We are glad to know that things are progressing with roswtf on WSL. Can you describe in little more detail about what the exact problem is when you say there appear to still be some unresolved issues in the network stack on WSL that prevent pub/sub to work reliably in both directions? This will help us know what needs to be done to unblock this further.

I just checked roswtf on my installation of kinectic. Since I disabled ipv6 the issue mentioned here does not show, however the issue mentioned by @sunilmut is very present.
jan@jan-pc:~$ roswtf
Loaded plugin tf.tfwtf
No package or stack in context
================================================================================
Static checks summary:

No errors or warnings
================================================================================
Beginning tests of your ROS graph. These may take awhile...
analyzing graph...
... done analyzing graph
running graph rules...
... done running graph rules

Online checks summary:

Found 1 warning(s).
Warnings are things that may be just fine, but are sometimes at fault

WARNING The following node subscriptions are unconnected:
 * /rosout:
   * /rosout

@lovettchris - Thanks for your post. Please try your scenario on 15007 and let us know if it still doesn't work.

On 15007 roswtf still complains that /rosout is not available. On the other hand, the ipv6 issue reported by @lovettchris seems to be fixed since there are no errors even though ipv6 is enabled.
´´´´
jan@jan-pc:~$ roswtf
Loaded plugin tf.tfwtf
No package or stack in context
Static checks summary:
No errors or warnings
Beginning tests of your ROS graph. These may take awhile...
analyzing graph...
... done analyzing graph
running graph rules...
... done running graph rules
Online checks summary:
Found 1 warning(s).
Warnings are things that may be just fine, but are sometimes at fault
WARNING The following node subscriptions are unconnected:

/rosout:

/rosout
´´´´

@janbernloehr - Thanks for trying this out in recent build and the update. Can you collect and share the strace of the failing roswtf command?
strace -o <strace_file> -ff roswtf

I created straces of roscore and roswtf on 15014.
roscore.tar.gz
roswtf.tar.gz

I have tested in build 15019, still not working.
Made straces from roscore and roswtf as well.
roscore.tar.gz
roswtf.tar.gz

any update? with the latest windows creator update?

See https://github.com/Microsoft/BashOnWindows/issues/1391 for the latest update

I have used the instruction for Ubuntu ROS installation to install ROS on Windows 10 Bash (WSL). It did install without complaining. I am also able to start the ROS master using roscore. However, I am not having so much luck with the debug (visualization tools). RViz just crashed after a segmentation fault and Gazebo open with a blank (greyed out) visualization window. Based on comments above, I see that its not expected to work rightaway. Perhaps this has to do something with OpenGL + NVIDIA (GeForce 920M) interface issues. Maybe compiling from source in WSL is the best option - but I am too faint of heart to try something like that. My system configuration is listed below for reference. Apologize for the long post.
vsampath@DESKTOP-548P7JD:~$ roscore &
[1] 8425
vsampath@DESKTOP-548P7JD:~$ ... logging to /home/vsampath/.ros/log/dbe0e326-736e-11e7-ab82-54ee7571850e/roslaunch-DESKTOP-548P7JD-8425.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.

started roslaunch server http://DESKTOP-548P7JD:59554/
ros_comm version 1.12.7

SUMMARY
========

PARAMETERS
 * /rosdistro: kinetic
 * /rosversion: 1.12.7

NODES

auto-starting new master
process[master]: started with pid [8436]
ROS_MASTER_URI=http://DESKTOP-548P7JD:11311/

setting /run_id to dbe0e326-736e-11e7-ab82-54ee7571850e
process[rosout-1]: started with pid [8449]
started core service [/rosout]

vsampath@DESKTOP-548P7JD:~$ rosrun rviz rviz
[ INFO] [1501230589.094844400]: rviz version 1.12.10
[ INFO] [1501230589.095276300]: compiled against Qt version 5.5.1
[ INFO] [1501230589.095559800]: compiled against OGRE version 1.9.0 (Ghadamon)
Segmentation fault (core dumped)

System config:
vsampath@DESKTOP-548P7JD:~$ sudo uname -mrs
Linux 4.4.0-43-Microsoft x86_64
vsampath@DESKTOP-548P7JD:~$ sudo lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    2
Core(s) per socket:    2
Socket(s):             1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 61
Model name:            Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz
Stepping:              4
CPU MHz:               2401.000
CPU max MHz:           2401.0000
BogoMIPS:              4802.00
Virtualization:        VT-x
Hypervisor vendor:     vertical
Virtualization type:   full
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave osxsave avx f16c rdrand

vsampath@DESKTOP-548P7JD:~$ sudo lshw
desktop-548p7jd
    description: Computer
    width: 64 bits
  *-core
       description: Motherboard
       physical id: 0
     *-memory
          description: System memory
          physical id: 0
          size: 8097MiB
     *-cpu
          product: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz
          vendor: Intel Corp.
          physical id: 1
          bus info: cpu@0
          capacity: 2401MHz
          width: 64 bits
          capabilities: fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp x86-64 pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave osxsave avx f16c rdrand cpufreq

vsampath@DESKTOP-548P7JD:~$ sudo lspci -vnn
pcilib: Cannot open /proc/bus/pci
lspci: Cannot find any working access method.

vsampath@DESKTOP-548P7JD:~$ sudo glxinfo | grep OpenGL
OpenGL vendor string: Mesa Project
OpenGL renderer string: Software Rasterizer
OpenGL version string: 1.4 (2.1 Mesa 17.2.0-devel (git-9ac55e8219))
OpenGL extensions:

I see from your output that you are using ros kinetic, the necessary patch, however, is only available for ros lunar.

Thanks Jan. For the record, installation based on ROS lunar resolved the ros_comm issue. However, WSL still seems to struggle with getting Gazebo visualization to work. Same setup for ROS lunar replicated on Raspberry Pi (display tunneled over X11 forwarding) seems to open Gazebo with visualization just fine. I opened a thread on Gazebo answers on this.

@svanimisetti - Thanks for your post. WSL's focus so far as been command line tools. Although, within that focus, graphical tools have been able to work with X11 forwarding. If you are having problems with the visualization on ROS, that would be a different issue than this one and I would recommend opening a new issue for that.

authors: Andersw88 MikeGitb gavanderhoorn janbernloehr lovettchris sunilmut svanimisetti sweetim

repo: Microsoft/BashOnWindows


text:
[.NET SDK] Try to make compatible with .NET Core 2.0

Related issue: #572
This is a rather tremendous PR and still in its preliminary stage. I place it here in the hope of demonstrating the feasibility to support ASP.NET Core 2.0, while to make sure that I haven't gone too wrong or too far. More commits are yet to be made.
Project structure
To keep the VS2015 solution intact, I named the VS2017 solution file Microsoft.Bot.Builder.2017.sln, placing it beside the original solution file. Likewise, the csproj files in VS2017 format (Roslyn?) has .2017 appended to the name of the files. If you want to compile the .NET Framework + .NET Standard NuGet packages, you will need to open Microsoft.Bot.Builder.2017.sln in VS2017.
While the two solutions use different project files, they share the same code files, except for the .NET Core specific ones.
The new csproj files has multiple targets (net45/netstandard1.6;net46/netstandard2.0), using MSBuild (VS IDE, to be more exact) to generate NuGet packages. I haven't figure out how to add pdb files to the packages in this way.
Current status
Only the checked projects can be loaded in the VS2017 solution.

Library

[x] Microsoft.Bot.Builder
[x] Microsoft.Bot.Builder.Autofac
[x] Microsoft.Bot.Builder.Calling
[x] Microsoft.Bot.Builder.FormFlow.Json
[x] Microsoft.Bot.Builder.History (No related example to test)
[x] Microsoft.Bot.Connector

Samples

[x] AlarmBot (net46)

[x] Microsoft.Bot.Sample.AspNetCore.AlarmBot (netcoreapp2.0)

[x] AnnotatedSandwichBot (ditto)

[x] Microsoft.Bot.Sample.AspNetCore.AnnotatedSandwichBot

[x] EchoBot

[x] Microsoft.Bot.Sample.AspNetCore.EchoBot

[x] PizzaBot

[x] Microsoft.Bot.Sample.AspNetCore.PizzaBot

[ ] SearchPoweredBots (Depends on published SDK packages)
[x] SimpleAlarmBot
[x] SimpleDispatchDialog
[x] SimpleEchoBot

[x] Microsoft.Bot.Sample.AspNetCore.Echo (Without Bot.Builder)

[x] SimpleFacebookAuthBot (Net tested yet.)

[x] Microsoft.Bot.Sample.AspNetCore.SimpleFacebookAuthBot (Tested with Facebook.)

[x] SimpleIVRBot (Not tested with Skype yet.)

[x] Microsoft.Bot.Sample.AspNetCore.SimpleIVRBot (Tested with Skype.)

[x] SimpleSandwichBot
[ ] Stock_Bot (Depends on published SDK packages)
[x] TemplateBot

Tests

[x] FormTest
[x] Microsoft.Bot.Builder.Tests (net46) (201/217 tests passed, same as before the migration)
[x] Microsoft.Bot.Sample.Tests (net46) (2/6 tests passed, same as before the migration)

Tools

No migration needed.

Modifications that affects the VS2015 solution
Microsoft.Rest.ClientRuntime 2.3.2 (netstandard) referenced by Bot.Builder has a dependency on Newtonsoft.Json 9.0.1. To keep the packagereference versions uniform, I have added a dependency on Bot.Builder to Newtonsoft.Json 9.0.1. This causes all the referencing .NET Framework samples to upgrade Newtonsoft.Json from 8.0.3 to 9.0.1.
It seems that now the Bot.Builder in VS2017 solution has an implicit dependency on System.Net.Http.dll v4.1.1, while the version provided by net46 is v4.0.0, so I simply changed the binding redirect in web.config files in the sample projects. It seems like a Heisenbug. The binding redirects has been removed.
I have migrated some methods in BotAuthenticator to make them consumable by ASP.NET Core, surrounded by #ifs. Some methods, e.g. TryAuthenticateAsyncWithActivity, now accepts the authentication header instead of the whole HttpRequestMessage. There are some conditional directives introduced to accommodate the difference between HttpRequestMessage in ASP.NET and HttpRequest in ASP.NET Core. These changes are made to the shared code files, but should have no actual impact on the VS2015 solution as well as the net45/net46 part of the VS2017 packages.
From ASP.NET to ASP.NET Core
There is no ConfigurationManager in ASP.NET Core, so I added SettingsUtils.AttachConfiguration and you need to call it upon initialization of the website (e.g. in Startup.ConfigureServices). This change will make sure the rest of SDK can be migrated seamlessly to ASP.NET Core.
I have migrated BotAuthenticationAttribute to ASP.NET Core. Now you can place it on your controller classes the same way when you are working with ASP.NET. When used along with Bot.Builder, the invocations of UseBotAuthentication can be removed in your Startup.Configure methods. See an ASP.NET Core example for reference.
BinaryFormatter
Some "polyfills" have been worked out in NetStandardSerialization.cs so that the .NET Standard/Core BinaryFormatter supports the serialization of Type, MemberInfo, Delegate, and Regex. This is soly for compatibility.

[x] TODO: For now the Type serialization surrogate does not support generics very well. Type.AssemblyQualifiedName is enough.

Package versions
As I have mentioned above, I have upgraded Newtonsoft.Json to 9.0.1 in VS2017 solution. I have also upgraded Autofac to 4.2.0 for netstandard2.0, which supports netstandard platform, but this time leaving the version unchanged (3.5.2) on net46. However, I wish it is allowed to unify the net46 and netstandard2.0 part of the dependency to v4.2.0.
There is currently no .NET Standard/Core compatible package for Chronic, so I used my .NET Standard port for Bot.Builder on netstandard2.0.

[ ] TODO: Fix warning MSB3277 on Bot.Builder project.

Tips

If you are met with error : Your project.json doesn't have a runtimes section. during compilation (esp. for vs2015 solution), remove obj/project.assets.json and the error should be gone.

@CXuesong,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by Microsoft. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

I think that's all. Except that I still couldn't resolve MSB3277 rises from Bot.Builder.2017 solution in a way without supressing it. (Found conflicts between different versions of the same dependent assembly that could not be resolved)

Any info when support for ASPNet Core 2.0 will be available?

@CXuesong , this is a great pull request.  I actually have on my plate today to start the work to port to .NET Core 2.0, I am going to sync with these changes, make sure they work and push it through unless I find some deal breaker.
Thanks for all of your work!  This is a big contribution!

@tomlm Any news on this?

@cleemullins - can you reference a link or smth about that feature in c# sdk v4 ?

source: gharchive/pull-request

authors: CXuesong hkusulja msftclas oscarwest tomlm

repo: Microsoft/BotBuilder

license: MIT

license_type: permissive

license_source: github-api


text:
Jwilaby/modal design pass

This PR removes ui-fabric from the modals and addresses the padding a size issues for the majority of the  Dialogs

Pull Request Test Coverage Report for Build 805

1 of 2 (50.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 45.659%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

packages/app/client/src/data/sagas/servicesExplorerSagas.ts
1
2
50.0%

Totals

Change from base Build 799:
0.0%

Covered Lines:
1183

Relevant Lines:
2373

💛  - Coveralls

authors: coveralls justinwilaby

repo: Microsoft/BotFramework-Emulator


text:
new marketing entities and new friendly names for entities and attrib…

…utes
adding the entities from the 'new' marketing app and some of the supporting framework. moved entities around in the hierarchy to represent the 'rings' of  extensions and dependencies that will actually happen in cds for applicatons

looking at different ways to do this...

repo: Microsoft/CDM


text:
Duplicate function declarations in blocks should throw early error in sloppy mode

{
    function foo() { }
    function foo() { }
}

Expected: Early syntax error. Actual: no error, second function wins always near as I can tell.
Duplicate function names are allowed at top level but not in blocks. Spidermonkey came across web compat issues trying to implement this, so are going to go more slowly. V8 has it in Canary and will test out these semantics in their Beta channel. Hopefully if all goes well there we can fix this bug without worry.

We ran into another compat issue with foxnews.com (serving Akamai's media player): https://code.google.com/p/chromium/issues/detail?id=579395

Thanks @ajklein. @bterlson sounds like we should leave ChakraCore as is and TC39 should amend the spec.

@ianwjhalliday Depends. I tend to think that not throwing an error here is bad for many reasons. If we are forced to support it due to web compat then we have no choice, but let's wait and see what data @syg's telemetry finds. Also perhaps Canary has telemetry enabled (@ajklein)? But I think it's safe to add ye olde pending TC39 consensus label :)

Consensus is we must allow duplicate func decls in blocks sloppy mode. tc39/ecma262#400 proposes a spec fix for this, but this issue can be closed!

source: gharchive/issue

authors: ajklein bterlson ianwjhalliday

repo: Microsoft/ChakraCore


text:
Three small fixes (build error, build warning, test input)

This fixes three small issues: a build error, a build warning, and an absolute path in a test input.

Thanks!

authors: FrancescoLogozzo wuestholz

repo: Microsoft/CodeContracts

license: mit

license_source: bigquery


text:
feat: error empty entity

Also clean up other replay error names for clarity

:tada: This PR is included in version 0.173.0 :tada:
The release is available on:

npm package (@next dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

authors: LarsLiden mattmazzola

repo: Microsoft/ConversationLearner-Models


text:
MixedRemoteViewCompositor crashes when stopping capture

when trying to close the capture a crash occurs.

the bug is un the StopCapture function of CaptureEngine.cpp. need to pass spThis into second (stopAsyncCB) lamda for critical section for reference count.
should be this:
auto stopAsyncCB = Callback(
[this, spThis](In IAsyncAction *asyncResult, In AsyncStatus asyncStatus) -> HRESULT

Do you mean ==>
auto stopAsyncCB = Callback(
[this, spThis] .....?

yes spThis should be passed into the Callback lambda. This will add a ref count so the critical section object will still be available.

I have a pull request pending to resolve this issue

#17 pull request to fix this issue

authors: bobbycho carmines

repo: Microsoft/HoloLensCompanionKit


text:
Build Window not displaying

I'm using Unity 5.4.0f3, whenever I try to show the Build Window Unity flashes and no window is displayed. When I set some breakpoints in OnGui of BuildDeployWindow I see it getting ticked, but no window is displayed. This is off of latest master as of writing.

Ok, must be something with my particular Unity instance, when I switch to another computer I don't experience the issue. Closing.

repo: Microsoft/HoloToolkit-Unity


text:
TapToPlace.cs : Fix parent movement logic

#405 had an issue with parent movement and rotation.
I simplified the logic and tossed out the "Relational Distance" and in its place just applied the movement vector the the parent object instead of the currently selected object which fix the issue of the Relational Distance becoming increasingly erroneous.

I see the fixes to movement, but I don't see any changes to rotation.

@keveleigh The rotation was broken with the old movement logic, but the same rotation logic works with this new movement method. I didn't actually make any changes to that bit, just deleted/rewrote that line of code a lot while writing the fix so forgot that it's actually the same as it was.

@madvlad Sounds good!

authors: keveleigh madvlad


text:
Created SessionManager.UI as a Universal App

The SessionManager.Universal.UI follows a lot of the structure and contents of the SessionManager.UI project. There are some key changes and refactors that have happened and I will try to list them below. The functionality of the app is similar to the one provided by the desktop version but there are still ways to improve either one. This is simply an initial build meant to kick-start further developments on the platform.
Key changes from the SessionManager.UI:

Added CrossPlatform classes to bridge functionality to UWP. Classes were imported from HoloToolkit-unity project. Copyright headers maintained where applicable
SharingClient.dll is copied via post-build script to ensure proper version and architecture are selected
Changes to XToolsApp.cs to support Connect() / Disconnect() rather than do it on initialize.

Some known limitations to be addressed in future:

Read server IP and User from a config file (did not use the XtoolsConfig.txt to give ability to connect/disconnect
App crashes in debug only when disconnecting.

Addresses #6. Hope this helps.

Hi @alexdrenea, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by Microsoft and real humans are currently evaluating your PR.
TTYL, MSBOT;

Thanks guys for all the feedback. Much appreciated. I will add my comments to each line and correct where applicable and make another commit soon.

Hi guys,
Any further comments or feedback on the pull request that I should update?

authors: alexdrenea msftclas

repo: Microsoft/HoloToolkit


text:
SpectatorViewPoseProvider won't compile

I haven't made any changes to the code, which was last updated 20 hours ago (6/13/18).  I am using the latest Visual Studio 2017.
Here are the errors/warnings:
Severity	Code	Description	Project	File	Line	Suppression State
Error (active)	E0312	no suitable user-defined conversion from "Concurrency::taskConcurrency::details::_BadContinuationParamType" to "Concurrency::task" exists	SpectatorViewPoseProvider	e:\Downloads\Hololens Spectator View Files\MixedRealityCompanionKit-master\SpectatorView\SpectatorViewPoseProvider\SpectatorViewPoseProvider\AnchorImporter.cpp	104
Error (active)	E2534	deduced return type "Concurrency::task<size_t>" conflicts with previously deduced type "Concurrency::task"	SpectatorViewPoseProvider	e:\Downloads\Hololens Spectator View Files\MixedRealityCompanionKit-master\SpectatorView\SpectatorViewPoseProvider\SpectatorViewPoseProvider\AnchorImporter.cpp	121
Error	C3487	'Concurrency::task<size_t>': all return expressions must deduce to the same type: previously it was 'Concurrency::task<_Ty>'	SpectatorViewPoseProvider	e:\downloads\hololens spectator view files\mixedrealitycompanionkit-master\spectatorview\spectatorviewposeprovider\spectatorviewposeprovider\anchorimporter.cpp	121
Error	C2440	'return': cannot convert from 'Concurrency::task<size_t>' to 'Concurrency::task<_Ty>'	SpectatorViewPoseProvider	e:\downloads\hololens spectator view files\mixedrealitycompanionkit-master\spectatorview\spectatorviewposeprovider\spectatorviewposeprovider\anchorimporter.cpp	121
Warning	C4973	'Windows::Perception::Spatial::SpatialAnchorTransferManager::TryImportAnchorsAsync': marked as deprecated	SpectatorViewPoseProvider	e:\downloads\hololens spectator view files\mixedrealitycompanionkit-master\spectatorview\spectatorviewposeprovider\spectatorviewposeprovider\anchorimporter.cpp	136
Warning	C4973	'Windows::Perception::Spatial::SpatialAnchorTransferManager::RequestAccessAsync': marked as deprecated	SpectatorViewPoseProvider	e:\downloads\hololens spectator view files\mixedrealitycompanionkit-master\spectatorview\spectatorviewposeprovider\spectatorviewposeprovider\anchorimporter.cpp	104
Warning	C4101	'StartSurfaceObserver': unreferenced local variable	SpectatorViewPoseProvider	e:\downloads\hololens spectator view files\mixedrealitycompanionkit-master\spectatorview\spectatorviewposeprovider\spectatorviewposeprovider\spatialmappingmanager.cpp	214
Full output:
1>------ Build started: Project: SpectatorViewPoseProvider, Configuration: Release x64 ------
1>co1>------ Build started: Project: SpectatorViewPoseProvider, Configuration: Release x64 ------
1>compilation object save succeeded; see E:\Downloads\Hololens Spectator View Files\MixedRealityCompanionKit-master\SpectatorView\SpectatorViewPoseProvider\x64\Release\SpectatorViewPoseProvider\SimpleLightingPixelShader.cso
1>compilation object save succeeded; see E:\Downloads\Hololens Spectator View Files\MixedRealityCompanionKit-master\SpectatorView\SpectatorViewPoseProvider\x64\Release\SpectatorViewPoseProvider\SolidColorPixelShader.cso
1>compilation object save succeeded; see E:\Downloads\Hololens Spectator View Files\MixedRealityCompanionKit-master\SpectatorView\SpectatorViewPoseProvider\x64\Release\SpectatorViewPoseProvider\SurfaceGeometryShader.cso
1>compilation object save succeeded; see E:\Downloads\Hololens Spectator View Files\MixedRealityCompanionKit-master\SpectatorView\SpectatorViewPoseProvider\x64\Release\SpectatorViewPoseProvider\SurfaceVertexShader.cso
1>compilation object save succeeded; see E:\Downloads\Hololens Spectator View Files\MixedRealityCompanionKit-master\SpectatorView\SpectatorViewPoseProvider\x64\Release\SpectatorViewPoseProvider\SurfaceVPRTVertexShader.cso
1>compilation object save succeeded; see E:\Downloads\Hololens Spectator View Files\MixedRealityCompanionKit-master\SpectatorView\SpectatorViewPoseProvider\x64\Release\SpectatorViewPoseProvider\PixelShader.cso
1>compilation object save succeeded; see E:\Downloads\Hololens Spectator View Files\MixedRealityCompanionKit-master\SpectatorView\SpectatorViewPoseProvider\x64\Release\SpectatorViewPoseProvider\VertexShader.cso
1>compilation object save succeeded; see E:\Downloads\Hololens Spectator View Files\MixedRealityCompanionKit-master\SpectatorView\SpectatorViewPoseProvider\x64\Release\SpectatorViewPoseProvider\VPRTVertexShader.cso
1>compilation object save succeeded; see E:\Downloads\Hololens Spectator View Files\MixedRealityCompanionKit-master\SpectatorView\SpectatorViewPoseProvider\x64\Release\SpectatorViewPoseProvider\GeometryShader.cso
1>pch.cpp
1>AppView.cpp
1>AnchorImporter.cpp
1>RealtimeSurfaceMeshRenderer.cpp
1>SpatialMappingManager.cpp
1>SpectatorViewPoseProviderMain.cpp
1>DeviceResources.cpp
1>CameraResources.cpp
1>SpatialInputHandler.cpp
1>SpinningCubeRenderer.cpp
1>e:\downloads\hololens spectator view files\mixedrealitycompanionkit-master\spectatorview\spectatorviewposeprovider\spectatorviewposeprovider\anchorimporter.cpp(121): error C3487: 'Concurrency::task<size_t>': all return expressions must deduce to the same type: previously it was 'Concurrency::task<_Ty>'
1>        with
1>        [
1>            _Ty=unsigned int
1>        ]
1>e:\downloads\hololens spectator view files\mixedrealitycompanionkit-master\spectatorview\spectatorviewposeprovider\spectatorviewposeprovider\anchorimporter.cpp(121): error C2440: 'return': cannot convert from 'Concurrency::task<size_t>' to 'Concurrency::task<_Ty>'
1>        with
1>        [
1>            _Ty=unsigned int
1>        ]
1>e:\downloads\hololens spectator view files\mixedrealitycompanionkit-master\spectatorview\spectatorviewposeprovider\spectatorviewposeprovider\anchorimporter.cpp(121): note: Constructor for class 'Concurrency::task<_Ty>' is declared 'explicit'
1>        with
1>        [
1>            _Ty=unsigned int
1>        ]
1>e:\downloads\hololens spectator view files\mixedrealitycompanionkit-master\spectatorview\spectatorviewposeprovider\spectatorviewposeprovider\anchorimporter.cpp(136): warning C4973: 'Windows::Perception::Spatial::SpatialAnchorTransferManager::TryImportAnchorsAsync': marked as deprecated
1>e:\downloads\hololens spectator view files\mixedrealitycompanionkit-master\spectatorview\spectatorviewposeprovider\spectatorviewposeprovider\anchorimporter.cpp(136): note: Message: 'Use SpatialEntityStore instead of SpatialAnchorTransferManager. For more info, see MSDN.'
1>e:\downloads\hololens spectator view files\mixedrealitycompanionkit-master\spectatorview\spectatorviewposeprovider\spectatorviewposeprovider\anchorimporter.cpp(104): warning C4973: 'Windows::Perception::Spatial::SpatialAnchorTransferManager::RequestAccessAsync': marked as deprecated
1>e:\downloads\hololens spectator view files\mixedrealitycompanionkit-master\spectatorview\spectatorviewposeprovider\spectatorviewposeprovider\anchorimporter.cpp(104): note: Message: 'Use SpatialEntityStore instead of SpatialAnchorTransferManager. For more info, see MSDN.'
1>SpectatorViewSocket.cpp
1>e:\downloads\hololens spectator view files\mixedrealitycompanionkit-master\spectatorview\spectatorviewposeprovider\spectatorviewposeprovider\spatialmappingmanager.cpp(214): warning C4101: 'StartSurfaceObserver': unreferenced local variable
1>SurfaceMesh.cpp
1>Done building project "SpectatorViewPoseProvider.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Please build as release x86.
the default now is debug x64 which surfaces these errors.

authors: fieldsJacksonG johnpquarles

repo: Microsoft/MixedRealityCompanionKit


text:
InputManager Singletons prevent using Multiple scenes

Overview
How is the Input system usable if you have multiple scenes using MRTK and one loading another?
I use the InputManager prefab in a Hololens menu scene, which then loads up another scene which also uses the InputManager.
Running both scenes alone is fine, but when one is loaded after the other the input system screws up and does not work anymore!!!!
Even the suggestion of having only one InputManager prefab in the menu scene does not work because the world space canvases in the to be loaded scene need a link to the EventSystem Raycast camera which is not possible this way.
Has anyone used MRTK to load multiple scenes? What do you do?
The 1.5.5 version was fine..... without the invasive new Singletons....
Here  are the error messages i get, the World space UI is not interactable anymore. An i assume nothing else would work either.

Thanks
Expected Behavior
The Input system should work acress scenes
Actual Behavior
It does not work, because the InputManager never dies and screws up input altogether.
Steps to reproduce
Just create 2 scenes using the InputManager where one scene loads another.
Unity Editor Version
2017.3.1
Mixed Reality Toolkit Release Version
2017.2.1.1

If i downgrade the Singleton to what it was before (No DontDestroyOnLoad) do i break anything else in MRTK?

I agree the current setup is not great for working with multi-scene projects. I have worked through the same issues which, though I'm always looking for a better work flow, I address as follows:

Having only a single Camera/Input/Cursor in the project, and only in the first scene makes it difficult to test any scene after the first one. To handle this, I place the MixedRealityToolkitCameraParent, InputManager and DefaultCursor in a separate scene (here named "WMRBase"). I add some code to run at each scene start to I check to see if this WMRBase scene has been loaded in the current scene, and if not do an additive load:

public const string WindowsMixedRealitySceneName = "WMRBase";

var wmrScene = SceneManager.GetSceneByName(WindowsMixedRealitySceneName);
if (!wmrScene.isLoaded) {
        SceneManager.LoadSceneAsync(WindowsMixedRealitySceneName, LoadSceneMode.Additive);
} else {
        var currentScene = SceneManager.GetActiveScene();
        SceneManager.MergeScenes(wmrScene, currentScene);
}

Cursor

Hi
thanks for the reply but this does not help in the case of world space canvases where you need a pointer to the EventSystem/RaycastCamera. Not to speak if you address the Cursor directly using Unity events.
Thanks for the pointer though. Was your message complete, i saw that you cut it off at point 2.

@MrDChristop The Camera issue was one I never really understood (despite @StephenHodgson's best efforts!). Initially I had to include the UpdateCanvasEventSystems line in my code, But, the issue is no longer there. I'm not sure if it was handled by some change in the dev branch, or by adding / removing the canvas's in the follow-on scene (maybe removing some cached reference).

I had issues getting the cursor to work with the EventSystem. Unity Buttons would work in the editor but not in the HoloLens emulator or on HoloLens. Maybe there is a fix for this, but I just removed the Unity buttons and replaced them with the UX buttons in the MRKT which don't have the issue (and are 3D which I wanted).

Having multiple scenes is vital and there should be provision for it. You proposed a nice workaround that does not work on all cases. I feel that these classes should not be on Unity DontDestroyOnLoad because they do more harm than good.

You can have multiple scenes, just don't put all the singleton classes in each one.

Stephen you saw my error messages. I use the InputManager prefab nothing out of the ordinary.
How would you setup 2 scenes  which use both MRTK input and one loads up the other?
The problem is that this results in error messages and in unusable World canvases.

If you were determined to allow for the MRKTCamera/Input/Cursor in each scene, you could attempt to undo the DontDestroyOnload property, but I think this would be difficult given the amount of interdependence each gameObject has and many of the nested scripts also have DontDestroyOnLoad. At least my naïve attempt (just now) to comment that out in the Singleton base class had issues.

Undoing DontDestroyOnLoad def created a mess. But the grabbing a reference, destroying them before loading the next scene and then reloading (or simply having the Camera/Input/Cursor in the next scene) seemed to work OK. Though not tested much to be sure.
Only mentioning this as something to explore if @MrDChristop wants to try a different work around for multi-scene projects. My current solution works well enough for me.

@MrDChristop Actually my scheme is specifically designed to allow you to test each individual scene. As the Camera/Input/Cursor are placed in their own standalone scene, when any of your scenes are first loaded you can first test if the scene containing the Camera/Input/Cursor scene has already been loaded. If not --whether you are starting with the first scene or a subsequent scene -- then you load it additively. If previously loaded then you already have a Camera/Input/Cursor available so you don't need to reload.
The cursor is a minor issue. The Input has a reference to the Cursor you can assign in the editor. It loses that reference in a follow-on scene if the Cursor doesn't survive from the scene where you first assigned it. It will find and reassign a new Cursor however, so it just prevents a small bit of extra processing, as well as keeping the Cursor scheme consistent with the Camera/Input (assuming you stick with the Singleton pattern.

Guys, most of these issues are getting address soon, we're moving away from using singletons in the project in as many places as possible.
Hopefully that'll solve much of the pain points here.

The approach you mentioned is really forcing you to work with a specific way only for the sake of keeping the classes as non destroyable singletons. Is this worth it? Is there really a specific reason you use Singletons other than ease of access in MRTK, does the InputManager or any other classes do soemthing that can be done only once?

Yeah pretty much for the sake of performance and more control over the lifecycles of the objects themselves.  Although, I thought that there is now a flag on the Singleton objects that should enable you to have the option of using DontDestroyOnLoad, (Or is that only in the dev working branch?)

Hey this may be a naive approach - but could you leave the InputManager and MixedRealityCameraParent in all scenes, but keep them inactive unless you're testing that particular scene?

Just chiming in to say that I have recently run into a similar scene-related InputManager issue.
I will often use a mostly-empty startup scene for initialization, then additively load a primary scene when I'm ready for user input.
When I attempted to follow this pattern for an MRTK immersive project the InputManager in my primary scene would crash.
Point being, I think MRTK has been a bit myopic about scene management up until now - I'm hopeful that the new manager classes will address this but it might be wise to create some automated scene loading tests to make sure we're not tying anyone's hands.

Closing issues older than 180 days. If this is still an issue, please reactivate with recent information.

authors: MrDChristop Railboy StephenHodgson beccannlittle genereddick wiwei

repo: Microsoft/MixedRealityToolkit-Unity


text:
vNext customer feedback: too much debug log spam when a system isnt running

Does this affect the legacy HoloToolkit (master) or the Mixed Reality Toolkit (mrtk_release)?
Mixed Reality Toolkit
Describe the bug
We have received direct feedback that when a system (ex: Teleport) is disabled, there can be a great deal of "debug log spam" when system and/or client code asks for the system (whenever they are requested, they attempt to lazy-initialize).
To Reproduce

Disable the Teleport system in the configuration profile
Enter play mode

Expected behavior
Minimal Debug.Log entries regarding the lack of a teleport system.
Actual behavior
An over abundance of Debug.Log entries that can, at times, hide log messages from the application.
Screenshots
If applicable, add screenshots to help explain your problem.
Unity Editor Version
Which Unity version(s) you've been able to reproduce the bug in.
Mixed Reality Toolkit Release Version
Which MRTK version(s) you've been able to reproduce the bug in.
Additional context
Add any other context about the problem here.

Not sure this constitutes a bug report, but yes systems shouldn't complain if something isn't immediately turned on.
Do we have a list of debug logs that need to be addressed?

Customer feedback needs to be captured. :)

Agreed. Just surprised to see feedback as a bug report.
Likely we'll need to add a flag in the static system property accessors that can silence after the first null return, and reset the flag after a valid one is found.

The other issue is that they failed to also remove any pointers/assets that are using the Teleport system.

Makes sense that they're getting logs about a system that doesn't exist if assets and things in the scene are searching for them.

authors: StephenHodgson davidkline-ms


text:
Enhanced Keyboard, fixed dictation, feedback on dictation actually doing something

Overview
Fixed keyboard dictation button - now actually shows some feedback, and recognized text is properly inserted. Some UI enhancements as well
Changes

Dictation now works
Dictation button is red when dictation is active
Keyboard automatically closes after a set time of inactivity
Includes method to set scaling from the outside by code
Includes method to set scaling from the outside by code
Text inside text field is bigger so it's actually readable
Remove ray cast hit from input field and prevent activation, as this brings up the SYSTEM keyboard in MR (not in HL)

This code is successfully deployed in Walk the World for both HoloLens and Immersive headsets

That is exactly what I am doing but OUTSIDE of this class. As this class doesn't automatically can start phrase recognition, shutting it DOWN automatically is wrong as well. That could go in a sample scene. Not in this class.
Joost van Schaik
Windows Development MVP
"The world as I envision it in my head is such a more interesting place"

From: Stephen Hodgson notifications@github.com
Sent: Saturday, December 9, 2017 11:02:07 PM
To: Microsoft/MixedRealityToolkit-Unity
Cc: Joost van Schaik; Author
Subject: Re: [Microsoft/MixedRealityToolkit-Unity] Enhanced Keyboard, fixed dictation, feedback on dictation actually doing something (#1496)
@StephenHodgson requested changes on this pull request.
We should be using the DictationManager class because it properly handles suspending the PhraseRecognizer
If you want to use both phrase recognition and dictation in your app, you'll need to fully shut one down before you can start the other. If you have multiple KeywordRecognizers running, you can shut them all down at once with:
PhraseRecognitionSystem.Shutdown();
In order to restore all recognizers to their previous state, after the DictationRecognizer has stopped, you can call:
PhraseRecognitionSystem.Restart();
You could also just start a KeywordRecognizer, which will restart the PhraseRecognitionSystem as well.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/MixedRealityToolkit-Unity/pull/1496#pullrequestreview-82336452, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AD8Bn6-cU1rw-rXtKJSdJNtQPQ2_Wa8xks5s-wNfgaJpZM4Q8RE8.

That's what I'm trying to say.  We should using the IDictationHandler.

You completely lost me here
Joost van Schaik
Windows Development MVP
Sent from mail for Windows 10
"The world as I envision it in my head is such a more interesting place"

From: Stephen Hodgson notifications@github.com
Sent: Sunday, December 10, 2017 7:08:12 PM
To: Microsoft/MixedRealityToolkit-Unity
Cc: Joost van Schaik; Author
Subject: Re: [Microsoft/MixedRealityToolkit-Unity] Enhanced Keyboard, fixed dictation, feedback on dictation actually doing something (#1496)
That's what I'm trying to say. We should using the IDictationHandler.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/MixedRealityToolkit-Unity/pull/1496#issuecomment-350566718, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AD8Bn1_duQ33MJWSCCryx-SZs7xyoz6gks5s_B4MgaJpZM4Q8RE8.

No worries, I'll open a PR on your branch with the requested changes.
Btw, thank you for doing this! It was sorely needed!

Stephen, since you apparently were occupied elsewhere I took a look at the PR myself and added improvements as per your remarks

We don't. Deleted those, as well as some other superfluous stuff I noticed when combing the code again

I am not entirely sure what happened here. I hope the PR is still okay to you now I fixed the isssues

All right, apologies for that last one. Have no idea what happened there. I am not exactly your Git guru ;)

Please look further down the commits. Something went wrong with a merge, I think
Joost van Schaik
Windows Development MVP
"The world as I envision it in my head is such a more interesting place"

From: Kurtis notifications@github.com
Sent: Friday, December 29, 2017 10:30:26 PM
To: Microsoft/MixedRealityToolkit-Unity
Cc: Joost van Schaik; State change
Subject: Re: [Microsoft/MixedRealityToolkit-Unity] Enhanced Keyboard, fixed dictation, feedback on dictation actually doing something (#1496)
@keveleigh commented on this pull request.

In Assets/HoloToolkit/UX/Scripts/Keyboard.cshttps://github.com/Microsoft/MixedRealityToolkit-Unity/pull/1496#discussion_r159105134:

         // Keep keyboard deactivated until needed

         gameObject.SetActive(false);
     }

   /// <summary>

   /// Recursive find. Potentially move to a child class.

   /// </summary>

   GameObject RecursiveFindChild(Transform parent, string childName)

Looks like this was removed in 9fc3badhttps://github.com/Microsoft/MixedRealityToolkit-Unity/commit/9fc3bade2abdc74c119d72240bff10f86fbf3ff9 but re-added in b4e8980https://github.com/Microsoft/MixedRealityToolkit-Unity/commit/b4e89803adf6b46c6770a8df869e5e590dc262d2. That second commit seems to have reverted both the first commit I linked and 0c6e01chttps://github.com/Microsoft/MixedRealityToolkit-Unity/commit/0c6e01c1ebc877f93ea52585318ae6b0c02e777b. Was that intended?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/MixedRealityToolkit-Unity/pull/1496#discussion_r159105134, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AD8Bn5wms2uYxU_nrMXxMrbY9jIVhx6qks5tFVnygaJpZM4Q8RE8.

@LocalJoost That comment was as of the latest commit, https://github.com/Microsoft/MixedRealityToolkit-Unity/commit/b4e89803adf6b46c6770a8df869e5e590dc262d2, which re-added some things you previously removed, like RecursiveFindChild in favor of Utils.GetChildRecursive.

@keveleigh You were right, of course, and I really wonder how this all came about. I guess it has something to do with my remote branch getting accidentally deleted. Anyway. I think I have now brought back everything that is supposed to be there

Looks good to me! Thanks for these fixes!

authors: LocalJoost StephenHodgson keveleigh


text:
Failing Tests

All Tests fail for any Katas in a system that runs fine with the erstwhile Quantum repository.

Thanks. Closed.

repo: Microsoft/QuantumKatas


text:
ES6 re-export breaks circular dependencies

TS version 2.2.1
// entry.ts
import * as a from './a'
console.log('entry', { a })
import * as b from './b'
console.log('entry', { b })

// a.ts
import * as b from './b'

console.log('a', { b })

export const Foo = 'Foo'

b.ts
export * from './a'

export const Bar = 'Bar'

When I run tsc --outDir target entry.ts && node entry.js, the output is:
a { b: { __esModule: true, Bar: 'Bar' } }
entry { a: { __esModule: true, Foo: 'Foo' } }
entry { b: { __esModule: true, Bar: 'Bar' } }

I expected both modules, a and b, logged from entry to include the Foo exported property, however this is only the case for a.

Just tested the same code with babel and it seems to work. The output becomes:
a { b: { Foo: [Getter], Bar: 'Bar' } }
entry { a: { Foo: 'Foo' } }
entry { b: { Foo: [Getter], Bar: 'Bar' } }

The circular dependency works because Foo is evaluated lazily.

I think this and #12522 share the same cause, namely the eager evaluation of re-exports (which should be lazy like they are in Babel).

authors: OliverJAsh yortus

repo: Microsoft/TypeScript


text:
Command line option descriptions should be more consistent

Consider the description for newLine and noEmit:

Option Name
Description

newLine
"Specifies the end of line sequence to be used when emitting files: 'CRLF' (dos) or 'LF' (unix)."

noEmit
"Do not emit outputs."

The two are phrased in different verb forms (and I'm sure @JsonFreeman could categorize them down perfectly).
These diagnostics should be consistent, and any changes should ideally be reflected on the respective wiki page: https://github.com/Microsoft/TypeScript-wiki/blob/master/Compiler-Options.md

Feel free to send a PR to clean them all up.

Good catch @DanielRosenwasser. The difference is the mood, which is indicative in the first and imperative in the second.
That said, I'm not sure the inconsistency is bad. The reason is that the subject of the first description is the compiler's option, whereas the subject of the second is the compiler's behavior. So different subjects might warrant different moods in this context. I'm inclined to say these two make sense the way they are.

@vladima was actually the one who caught this. Still I'm not sure the compiler should go through grammatical mood swings between a list of options.

Haha, mood swings. I think it's fine to make it consistent mood, but you may have to change the subject of the phrase to do so. How about this

Use the specified end of line sequence when emitting files

The other difference btw is the negation in "Do not emit outputs". Consider what it would sound like if the option was "Does not emit outputs". The natural question would be "well then, what does it do?"

Hah, yeah, I had a hard time figuring out a better way to make noEmit's message consistent with newLine, but the opposite switch seems slightly easier.

authors: DanielRosenwasser JsonFreeman mhegazy


text:
Please confirm the equivalent MSBuild tag for --jsx

This Wiki article is missing the MSBuild tag for --jsx:
https://github.com/Microsoft/TypeScript/wiki/Setting-Compiler-Options-in-MSBuild-projects
I can add it if you're willing to just confirm it.  Thanks!  (Note I'm only asking due to the case-sensitive nature of it)

@paulvanbrenk

The MSBuild element to use is <TypeScriptJSXEmit> with React, or Preserve as the value.

Thanks!  I'll issue a PR on the Wiki.

the source of truth is your targets file at C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\TypeScript\Microsoft.TypeScript.targets..
look for the sections setting TypeScriptBuildConfigurations

authors: DanielRosenwasser mhegazy nycdotnet paulvanbrenk


text:
Fail speculative parsing of arrow functions when their parameter initialisers are missing a =

Fail speculative parsing of arrow function expressions whenever it has a parameter with an initialiser that is missing '='. Ordinarily this is allowed for better error recovery in the language service, but for speculative parsing, the errors can compound. When the initialiser is an error, and when the '=>' is missing (which is also allowed), what is putatively an arrow function may actually be something else.
For example, (a / 8) + function () { } is currently parsed as if someone had intended to write
(a = /8)+function()/) => { } but they forgot the = of the
initialiser, the => of the lambda, forgot to close the regular
expression, and mistakenly inserted a newline right after the regular
expression.
I need to test whether this causes problems when using the language service, but I do not think that it will.
Fixes #18158
Fixes #18406
Fixes #18306

The editor experience seems OK to me, but admittedly it's hard to judge when trying it with preconceptions.

We will need to port this to release-2.5 as well.

It is now in release-2.5 too.

authors: mhegazy sandersn


text:
Change the default LS target to ES5 from ES6

Fixes ##1722. This allows the VS Language Service to default to ES5, instead of ES6 (latest)

:+1:

:+1:

:+1:

authors: JsonFreeman mhegazy sheetalkamat vladima


text:
Add directory watcher in inferred projects

This PR added directory watchers in inferred projects to detect the addition of tsconfig.json in the future. This fixes the workaround for issue #3244.

as we talked offline, closing this in favor of a PR addressing #4643 instead.

authors: mhegazy zhengbli


text:
Change file watching back to polling.

We tried the non-polling solution for file watching since last year, and it kept causing us a number of problems regarding watcher instance count limit, cross-platform compatibility, file locking, network file system compatibility etc; while the gain wasn't quite significant to justify all the efforts spent fixing these issues. Therefore it may be better to just go back to polling, which worked reliably for us before and don't have these problems.

My experience with file watching has been similar : https://github.com/TypeStrong/atom-typescript/blob/master/docs/faq.md#atom-typescript-is-complaining-about-not-finding-files-or-other-weird-errors
However with alm tools I am going with a dedicated process to do the disk watching (design) and it hasn't failed me on my system. Of course it might start to be a problem as more people use it. An additional of-course is that I offload the logic to https://github.com/paulmillr/chokidar since I have the luxury to use any npm package I want because package size isn't a concern for me yet :rose:

Would this revert to polling for all platforms? If so, then I would be against this change. I don't think it needs be a black-or-white solution; if platforms support a fast non-polling approach we should take advantage of that rather than revert to the lowest common denominator.
To that end, is there merit in having this be option-driven until such a time as the platform-support detection is refined?
--watch      # non-polling
--watchPoll  # polling

Or simply utilise some external library/binary that does this well already - have Watchman et al not come up with solutions/compromises already?

@basarat Thanks for sharing your experience! We considered chokidar too, but in the end we don't want to add the first dependency to the repo, and they inherited some of the limitation of node file watching too (lock parent folder for example). Plus the package size concern as you described.
@myitcv having different implementation for different systems means a more issues to maintain. And sometimes differentiating by OS doesn't help, for example in cases like mounted network folders, or folders shared between virtualbox host and guest OSes, which are hard to detect in the first place because node only tell us that much. As far as I know, some of the problems we encountered are also problems for Watchman and Chokidar (see https://github.com/Microsoft/TypeScript/issues/7420 and https://github.com/paulmillr/chokidar/issues/446), we need to have stronger reasons to add the first dependency for the repo. We didn't have any of these problems when using polling.
In terms of the option-driven route, we still need to decide the default behavior. If we set it to polling, which is not likely to cause many issues and therefore will become the majority of cases anyway. In addition, it may lead to new issues (imaging if the default mode is polling and you have a non-polling project open, and then you deleted the tsconfig.json so your opened files become loose files, then many things need to happen to make it right). So I lean towards just to keep the implementation simple for now, and in the future maybe hand the task off to editors, or add the non-polling option when node's native file watching becomes more mature.

@zhengbli thanks for the response. Agree it is indeed a case of striking a balance.

having different implementation for different systems means more complex logic and more issues to maintain

Indeed, but if you only provide a polling option you don't eliminate all issues (see below)

And sometimes differentiating by OS doesn't help, for example in cases like mounted network folders, or folders shared between virtualbox host and guest OSes, which are hard to detect in the first place because node only tell us that much

Indeed, which is why having the option to switch is critical (this is what I meant by my comment of the auto-detection logic not ever being perfect)

we need to have stronger reasons to add the first dependency for the repo

Totally your call, I was simply pointing out that you end up solving the same problems, suffering from the same issues etc.

We didn't have any of these problems when using polling.

No but you did have this problem - and I don't think that goes away... unless I'm mistaken?

In terms of the option-driven route, we still need to decide the default behavior. If we set it to polling, which is not likely to cause many issues and therefore will become the majority of cases anyway

I guess it depends how many projects are large projects, where large is defined in terms of the number of files sufficient to trigger the aforementioned problem

in the future maybe hand the task off to editors

... or some other process. You could even define an API by which another process can "poke" the compiler.

non-polling option when node's native file watching becomes more mature.

I guess my objection to this is that you are taking away the non-polling option until it becomes "more mature" - we don't have a clear idea of when that will be.
Can you not simply put the non-polling option behind a flag for now, in lieu of any other non-polling solution?

:+1:

@myitcv The problem you mentioned would be there after this change. We used to have different polling implementation for tsc and tsserver, then we unified them for the sake of simplicity, which caused the slowness for tsc if polling was used. With simply fs.watchFile, change detection should be fast, though CPU consumption may be a little higher.
We can keep both and add an environment variable to switch to non-polling for tsc. I'll update soon.

We can keep both and add an environment variable to switch to non-polling for tsc. I'll update soon.

@zhengbli - thanks

Should this be fixed in v2.3.4? I'm getting npm install errors when VS Code is open. Always need to close it.

authors: basarat fedu mhegazy myitcv zhengbli


text:
[Annotations]: ODataVocabularyReader does not gracefully fail for unknown annotations.

ODataVocabularyReader aggressively throws exceptions whenever it encounters annotations it is  unable to parse.
"ODataVocabularyReader.GetOdcmAnnotations" parses and creates a list of 'OdcmVocabularyAnnotation'. But this list not currently used by the odcmwriters to do anything useful. So I have removed the call to "ODataVocabularyReader.GetOdcmAnnotations" as a workaround (See PR #85 ).
FYI @MrTomWhite

:+1:

Issue doesn't exist anymore in current code based on removal.

authors: MrTomWhite Sridhar-MS mattgeim

repo: Microsoft/Vipr


text:
Unable to use Applinks part of Bolts API with WINOBJC

The Applinks part of Bolts(1.8.4) ObjC API is custom made for ios platform. To make this transportable through the bridge and make it work I think first it should have the capability to read the "al:" properties of  tags on the hosted HTML head element of the web page. The current API only reads the ios related Applinks in the HTML meta tags.
environment
I am using latest visual studio 2015 community version and win 10 sdk 14393 version and latest WINOBJC release on Feb1st

App linking from Facebook:
https://developers.facebook.com/docs/applinks/metadata-reference

authors: andrejo-msft venkatkongara

repo: Microsoft/WinObjC


text:
Get and stay current with third-party dependencies

libxml2
libz
cassowary?

we have local patches to 0.60; they may not be portable

icu

remove, depend on Windows inbox ICU (10.0.15063+)

#2051 tracks switching to inbox ICU

libxml2 must be rebuilt with new ICU.


text:
Adding uikit.xaml.pri back to nuspec.  I accidently removed it.

This change is

@jaredhms is added to the review. #Closed

:shipit:

authors: jaredhms pradipd


text:
Support opacity and interpolation for Drawing Images

This change is

:shipit:

authors: MSFTFox msft-Jeyaram


text:
Breaking changes in the new release

After upgrading to 1.1 404 is returned to all webapi requests.
After upgrading to .Net Core 1.1, it took me one day of work to understand that my WebApi was returning 404 to all requests because I did not added:  app.UseApiVersioning(); in the Startup class.
Maybe you should throw an exception when AddApiVersioning is used but UseApiVersioning is not? Returning 404 does not seem to be the answer.....

Sadly, it's easier said than done. I've considered and wanted to do something obvious like throw an exception when app.UseApiVersioning isn't configured. In fact, I was really hoping to not need that at all. Unfortunately, there's just no way around it. I've yet to find a way or place where such an exception could be thrown. What app.UseApiVersioning really does is add a special route to handle the API versioning policy. It is functionally similar to how app.UseMvc works, which will also not throw an exception if you forget to register it.
Worse still, even if I could figure out how and where to throw an appropriate exception, that wouldn't solve everything (although arguably the most common issues). Since app.UseApiVersioning adds a new router and routers are executed as a Chain of Responsibility, the order in which they are registered matters. If app.UseApiVersioning is called out of sequence, things will not work. On a positive side, this behavior seems to only have affected a few people (only one related issue has been reported).
In the interim, the best solution I have so far was to update the documentation everywhere. The release notes have called out the changes since the RC. All of the wiki and code samples have been updated. I even updated the landing page to remind people to read the release notes. Unfortunately, I can't make people read the content.
@Anyone, if you can think of a way to throw an exception or fail in some other spectacular way when things are not configured correctly, I'm listening. I'll consider suggestions, ideas, or even PRs. I haven't given up on solving this challenge and making the upgrade experience better. I support the principle of least astonishment.

I understand and fortunately I at the end found the release notes of the Asp Net Versioning.
Honestly I read the release notes for the 1.1 version and I have not seen this information about breaking changes (see here, here, here,....
On another note, I wanted to know: is there a possiblity to debug the 404 error in the Aspnet core application? I often find myself commenting/uncommenting code just for understanding why I get a 404 code because there is no debug logs. I tried the Aspnet core Diagnostics Elm but it throws exceptions + it does not seem to have more information than the ones displayed in the console logs.

In general, I don't know of any great ways to troubleshoot 404. API Versioning in ASP.NET Core 1.1+ exacerbates the problem when things are not configured properly because the IActionSelector intentionally indicates that it has not found a match, even if it has. This is a limitation in the way that ASP.NET Core works and is currently the only way to ensure that all possible action candidates have been considered. It's definitely something worth investing in. If you have some specific ideas or wants, it might be worth spinning up a new issue titled something along the lines of "Improve Logging and Diagnostic Information" with your requirements and/or ideas.

@ales004, @idevtech, @Alezis, @irowbin, @exiled78, @YogirajA, @Eneuman, @matteobortolazzo, @ericvan76, @TonyCasey
If I've called you out in the list, it's because you have recently filed an issue or otherwise commented on issues relating the upgrade for API versioning in ASP.NET Core from 1.0 to 1.1; specifically, related to the new requirement configuration to call app.UseApiVersioning.
I never like this new addition and up until now, I haven't been able to find any alternatives. I let the RC bake in for a while and the change didn't seem to hang up the early adopters much, so I felt comfortable going forward with the stable release.
It's clear now that, this new requirement is hanging up a lot of people. Despite all the documentation and issues, I suspect more issues will keep coming in. I'm hearing the feedback and I've been scrambling for a better approach. I'm happy to report that I believe I've found an alternative that gets rid of the need to have app.UseApiVersioning at all. I was able to run through all the test cases and some repros that you have provided. Everything still works. :)
I've published 1.2.0-beta1 of the package that includes the update. If at least a few of you can verify that change doesn't break you (obviously, minus the removal of app.UseApiVersioning), then I feel good about promoting the package to the stable 1.2.0 release.  This would also have the added benefit of removing knowledge about the order in which things must be registered (e.g. app.UseMvc, then app.UseApiVersioning, then app.MapWhen, etc, etc). It also appears that the majority of devs are still using 1.0.x based on the download numbers. Should things pan out. I'm considering delisting the 1.1.x packages altogether so people stop running into these landmines.
If three or more of you can take a few minutes to verify, I think that puts everyone in a good state and we can remove this snare for good. Thanks for your help and your voices that this needed to be improved.

I would suggest clean 'app.UseApiVersioning' and mark it as obsoleted, and
remove it in a later version. It's a bit annoying adding and removing
things so quickly. Most of people won't check the document when they
upgrade a package. Anyway I will test new version and let you know later
today. :)
On Fri, 30 Jun 2017 at 4:10 am, Chris Martinez notifications@github.com
wrote:

@ales004 https://github.com/ales004, @idevtech
https://github.com/idevtech, @Alezis https://github.com/alezis,
@irowbin https://github.com/irowbin, @exiled78
https://github.com/exiled78, @YogirajA https://github.com/yogiraja,
@Eneuman https://github.com/eneuman, @matteobortolazzo
https://github.com/matteobortolazzo, @ericvan76
https://github.com/ericvan76, @TonyCasey https://github.com/tonycasey
If I've called you out in the list, it's because you have recently filed
an issue or otherwise commented on issues relating the upgrade for API
versioning in ASP.NET Core from 1.0 to 1.1; specifically, related to the
new requirement configuration to call app.UseApiVersioning.
I never like this new addition and up until now, I haven't been able to
find any alternatives. I let the RC bake in for a while and the change
didn't seem to hang up the early adopters much, so I felt comfortable going
forward with the stable release.
It's clear now that, this new requirement is hanging up a lot of people.
Despite all the documentation and issues, I suspect more issues will keep
coming in. I'm hearing the feedback and I've been scrambling for a better
approach. I'm happy to report that I believe I've found an alternative that
gets rid of the need to have app.UseApiVersioning at all. I was able to
run through all the test cases and some repros that you have provided.
Everything still works. :)
I've published 1.2.0-beta1
https://www.nuget.org/packages/Microsoft.AspNetCore.Mvc.Versioning/1.2.0-beta1
of the package that includes the update. If at least a few of you can
verify that change doesn't break you (obviously, minus the removal of
app.UseApiVersioning), then I feel good about promoting the package to
the stable 1.2.0 release. This would also have the added benefit of
removing knowledge about the order in which things must be registered (e.g.
app.UseMvc, then app.UseApiVersioning, then app.MapWhen, etc, etc). It
also appears that the majority of devs are still using 1.0.x based on the
download numbers. Should things pan out. I'm considering delisting the
1.1.x packages altogether so people stop running into these landmines.
If three or more of you can take a few minutes to verify, I think that
puts everyone in a good state and we can remove this snare for good. Thanks
for your help and your voices that this needed to be improved.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/aspnet-api-versioning/issues/152#issuecomment-312061437,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJCzmtVN7WeMP-XqrTx_0qooERk-vaeks5sI--5gaJpZM4OIFbL
.

I hear you. I hate flip-flopping. I considered just making it obsolete. It's not off the table - yet. That was always the eventual plan. Not sure if anyone else has an opinion on the matter. I could equally just leave the method in place and have it do nothing. Thanks for help with the verification.

1.2.0-beta1 works well here.

Hi Chris
Tested 1.2.0-beta1 and it appears to work correctly.
Chris
On Thu, Jun 29, 2017 at 2:40 PM, Chris Martinez notifications@github.com
wrote:

@ales004 https://github.com/ales004, @idevtech
https://github.com/idevtech, @Alezis https://github.com/alezis,
@irowbin https://github.com/irowbin, @exiled78
https://github.com/exiled78, @YogirajA https://github.com/yogiraja,
@Eneuman https://github.com/eneuman, @matteobortolazzo
https://github.com/matteobortolazzo, @ericvan76
https://github.com/ericvan76, @TonyCasey https://github.com/tonycasey
If I've called you out in the list, it's because you have recently filed
an issue or otherwise commented on issues relating the upgrade for API
versioning in ASP.NET Core from 1.0 to 1.1; specifically, related to the
new requirement configuration to call app.UseApiVersioning.
I never like this new addition and up until now, I haven't been able to
find any alternatives. I let the RC bake in for a while and the change
didn't seem to hang up the early adopters much, so I felt comfortable going
forward with the stable release.
It's clear now that, this new requirement is hanging up a lot of people.
Despite all the documentation and issues, I suspect more issues will keep
coming in. I'm hearing the feedback and I've been scrambling for a better
approach. I'm happy to report that I believe I've found an alternative that
gets rid of the need to have app.UseApiVersioning at all. I was able to
run through all the test cases and some repros that you have provided.
Everything still works. :)
I've published 1.2.0-beta1
https://www.nuget.org/packages/Microsoft.AspNetCore.Mvc.Versioning/1.2.0-beta1
of the package that includes the update. If at least a few of you can
verify that change doesn't break you (obviously, minus the removal of
app.UseApiVersioning), then I feel good about promoting the package to
the stable 1.2.0 release. This would also have the added benefit of
removing knowledge about the order in which things must be registered (e.g.
app.UseMvc, then app.UseApiVersioning, then app.MapWhen, etc, etc). It
also appears that the majority of devs are still using 1.0.x based on the
download numbers. Should things pan out. I'm considering delisting the
1.1.x packages altogether so people stop running into these landmines.
If three or more of you can take a few minutes to verify, I think that
puts everyone in a good state and we can remove this snare for good. Thanks
for your help and your voices that this needed to be improved.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/aspnet-api-versioning/issues/152#issuecomment-312061437,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAdqcgaJRdgdjVuVAXvT70_o9C4TjZVFks5sI--5gaJpZM4OIFbL
.

Great! Thanks for confirming. I think we're about good.
A final question to the community. There are a couple of ways that app.UseApiVersioning can be sunset.
Option 1
Just delete it. This is the case in the 1.2 beta. I agree it's lame to add it, only to subsequently remove it so quickly. The only positive note is that adoption for 1.1 is only at about %1 of 1.0.x. Given the low adoption and how much trouble it's caused people, I'm ready to ditch it all together. The need to remove it is obvious, provides better continuity with 1.0.x, and has a relatively low negative impact.
Option 2
Another option is to keep app.UseApiVersioning, but turn it into a no-op method. I would also hide this method from Intellisense. I'm debating whether adding [Obsolete] is worth it. Personally, I don't like warnings in my code, so if I saw a warning that it's obsolete, then I'd remove the code altogether. If that's the general behavior, then why bother supporting that for 1% of users? I might as well go with Option 1 in that case. If I don't mark app.UseApiVersioning as [Obsolete], you won't get any ugly error messages and it won't do anything. That would be the smoothest, quietest transition for folks that went to 1.1, but are now moving to 1.2. People that move straight to 1.2 will never notice the difference.

The future direction will definitely be to:

Remove app.UseApiVersioning in 2.0, which isn't all the far off
Optionally, unlist the 1.1 package; it's caused enough pain that for those who haven't gone to 1.1 yet,
I'd rather just have them go straight to 1.2.

Thoughts? Votes?  Thanks.

My vote is Option 1 and remove the 1.1 build. Why keep something around
that could cause other people problems.
Chris
On Fri, Jun 30, 2017 at 9:07 PM, Chris Martinez notifications@github.com
wrote:

Great! Thanks for confirming. I think we're about good.
A final question to the community. There are a couple of ways that
app.UseApiVersioning can be sunset.
Option 1
Just delete it. This is the case in the 1.2 beta. I agree it's lame to
add it, only to subsequently remove it so quickly. The only positive note
is that adoption for 1.1 is only at about %1 of 1.0.x. Given the low
adoption and how much trouble it's caused people, I'm ready to ditch it all
together. The need to remove it is obvious, provides better continuity with
1.0.x, and has a relatively low negative impact.
Option 2
Another option is to keep app.UseApiVersioning, but turn it into a no-op
method. I would also hide this method from Intellisense. I'm debating
whether adding [Obsolete] is worth it. Personally, I don't like warnings
in my code, so if I saw a warning that it's obsolete, then I'd remove the
code altogether. If that's the general behavior, then why bother supporting
that for 1% of users? I might as well go with Option 1 in that case. If I
don't mark app.UseApiVersioning as [Obsolete], you won't get any ugly
error messages and it won't do anything. That would be the smoothest,
quietest transition for folks that went to 1.1, but are now moving to 1.2.
People that move straight to 1.2 will never notice the difference.
The future direction will definitely be to:

Remove app.UseApiVersioning in 2.0, which isn't all the far off
Optionally, unlist the 1.1 package; it's caused enough pain that for
those who haven't gone to 1.1 yet,
I'd rather just have them go straight to 1.2.

Thoughts? Votes? Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/aspnet-api-versioning/issues/152#issuecomment-312401370,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAdqckK1yYAIa36Qblbk-NeuelJm71elks5sJZu5gaJpZM4OIFbL
.

@commonsensesoftware Thanks for the update! I tested the beta package and it worked on my machine :) I didn't test it in our test environments. I'd like to vote for option1 since there was such low adoption of the new package. Can you make the one with app.UserApiVersioning unavailable in the nuget before more people download it? Thanks again

I recommend removing the 1.1.1 package, I've just been bitten by this. Updating to 1.2.0-beta1 fixed my issue.

Same here - it has been two days of research until I found out that it was the update of this nuget package that caused the 404 errors in my net core mvc app. Fortunately I have found this thread here, that helped me fixing it by adding app.UseApiVersioning(). I would also recommend unlisting the 1.1.1 package and making the current beta stable to be released ;)

Thanks for all the feedback, suggestions, and verifications.  Here's the final course of actions:

[x] The majority consensus was to remove rather than hide app.UseApiVersioning; it's gone
[x] 1.2.0 has been officially published ( releases | nuget )
[x] Versions 1.1.0-rc through 1.1.1 have been unlisted to avoid possible confusion
[x] All samples and wiki topics have stricken app.UseApiVersioning; I saved one side note in the known limitations section for historical documentation
[x] To make sure no one accidentally picks up a 1.1.x version as a transitive dependency, I've also updated the API Explorer package to 1.0.1 where it uses >= 1.2.0 of API Versioning

authors: YogirajA ales004 commonsensesoftware ericvan76 gabrielweyer idevtech logischdenker

repo: Microsoft/aspnet-api-versioning


text:
CRC Error with Release 1.2.1

Last release 1.2.1 for Arduino seems to have a CRC issue.

thank you for pointing this our, this dl url has been fixed, please clean the folder C:\Users[your name]\AppData\Local\Arduino15\staging\packages, re-open the boards manager to upgrade the new package

repo: Microsoft/azure-iot-developer-kit


text:
Nuget publishing task tries to upload .snupkg packages twice

Required Information
Question, Bug, or Feature?
Type: Bug
Enter Task Name: NuGet
Environment
account name: trwalke,
team project name: Identity Division IDDP (https://identitydivision.visualstudio.com/IDDP)
build definition name/build number: .NET MSAL V3 Release/ release Id=13717

Agent - Hosted or Private:

Hosted agent on "Hosted VS2017"

Issue Description
We are trying to us the nuget task to push our nuget packages and symbols via the .snupkg. The task is able to successfully upload the .nupkg and the .snupkg packages. However, it tries to upload the .snupkg again after it has already been uploaded resulting in an error.
We are using nuget version 5.0.0.5923 via the nuget tool installer.
We are simply pointing the nuget task to a folder that contains both .nupkg and the .snupkg packages
Task logs
ReleaseLogs_13717.zip
"Nuget Push" logs
Error logs

The nuget command failed with exit code(1) and error(Response status code does not indicate success: 409 (It looks like there is another copy of this symbols package pending validation(s). Please wait for the validation(s) to finish before trying to replace the symbols package.).)

The task documentation says we can use the "Index Sources & Publish Symbols task" for pushing symbols but that task doesnt seem to support .snupkgs.
https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/package/nuget?view=azure-devops

any updates on this?

Apologies for the slow response. Please try excluding the .snupkg file using the search pattern in the task input (the field called "Path to NuGet package(s) to publish"). From the logs, it looks like you are setting it to "C:\Nuget*.*nupkg", which will also match .snupkg files; please try removing the second wildcard character. The .snupkg is already automatically pushed by nuget.exe when the .nupkg is pushed; this behavior is mentioned in the third item in these docs.
The task runs nuget.exe push on every file matched by the search pattern. In this case, what's happening is that it's matching both files, running nuget.exe push on the .nupkg (which will also upload the .snupkg), then running it on the .snupkg, and failing.

authors: salvmd trwalke

repo: Microsoft/azure-pipelines-tasks


text:
Align some naming convention with spring boot.

Rename clientId -> client-id, clientSerect -> client-serect

Rename azureservice -> azure.service

Signed-off-by: Pan Li panli@microsoft.com
Summary

Issue Type

New Feature
Bug fixing

Starter Names

active directory spring boot starter
documentdb spring boot starter
key vault spring boot starter
media services spring boot starter
service bus spring boot starter
storage spring boot starter

Additional Information

refs #281

@snicoll

authors: Incarnation-p-lee sophiaso yungez

repo: Microsoft/azure-spring-boot


text:
Implement selected row highlighting

Currently the highlighting works if we hover over a row in a query (works only for when we select the data, not when we open them in edit data mode)
But what I would like to have is the ability to select a row, so when I'm scrolling to the right (horizontally) it keeps selected so I know what data I'm looking at.
Right now I need to use Mouse 3 and slowly move to the right or keep my mouse on that row and move to the right so I don't loose focus.
I'm attaching a small GIF, where I'm trying to focus on a row, and then scroll vertically and horizontally, but the row focus is loosing.

Feel free to ask for more details if needed.

seconded

authors: arcticwhite tholap

repo: Microsoft/azuredatastudio


text:
3240: Empty cells show thick border

Apply css to create border only when there is output.

@kevcunnane
The reason I separated two different classes for markdown and output is that we may have potential enhancements to them independently going forward. Please let me know your thoughts. I can merge them together if needed.
Talking about the implementation, Agree on hooking up the class at output-area-component level. However, I am little confused as to how we would do the same on markdown since it's got the default text and component is shown both in edit/preview modes.

Refactored the existing implementation. Please let me know your comments.


text:
Fix casing on welcome page to be consistent

Fix #5165.
Before:

After:

Might want to change the localization tag so it doesn't mess with the old strings.

I think the localization should be fine since its in a different file and the nls stuff runs partly on files.

authors: abist anthonydresser chlafreniere


text:
Add more Java examples

Port blob, enumerations, and import examples from C#.
Note Java version of import example is named "imports" here due to reserved word in Java.

CR comments addressed. Please squash into a single commit when merging.

Merging now (by hand to deal with the fixups).

Merged into the jvm branch in commit 6a571447928b80cb4d0b2523959f3ca319bbdf16.

authors: chadwalters chwarr

repo: Microsoft/bond


text:
[Core-Extensions] MessageFactory Tests perform a redundant assert

This line of code appears in multiple tests:
assert(activity.suggestedActions && activity.suggestedActions, `actions not returned`);

@Stevenic, is it supposed to be this?
assert(activity.suggestedActions && activity.suggestedActions.actions, `actions not returned`);

Tests:

should return suggestedActions().
should return suggestedActions() with text.
should return suggestedActions() with text and speak.
should return suggestedActions() with text, speak, and inputHint.

Yes.. good catch. Want to fix and submit a PR? If not I'll add the fix to one of my future PR's.

Sure, I'll have a PR ready today.

Thanks :)

repo: Microsoft/botbuilder-js


text:
error APPX0702: Payload file '...\HelloWorld_Uwp.winmd' does not exist.

I started with the Direct2d sample and incrementally modified to suit my needs. I use VS2017. I get the above error. How did the 'app.winmd' get generated ? Normally, it's part of the build process. But the sample seems to hardcode the file and contents ? How I generate HelloWorld_Uwp.winmd for my app ?

See here for guidance.   Alternately, if the dependency was inadvertent and unnecessary, you can set the Generate Windows Metadata linker switch to No (/WINMD:NO)

Thank you. I had to set /WINMD:NO.

I follow this: https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/interop-winrt-cx
first build success, but when i change type build (debug/release, x64/x86) i got
Error APPX0702 Payload file '\Debug<proj name><proj name>.winmd' does not exist.
Generate Windows Metadata linker was switch to No.
I was change back, but it n't work.

repo: Microsoft/cppwinrt


text:
Show custom fields on cards

Add support for displaying custom fields on the epic and feature cards. This would allow, for example, displaying a more granular status field, blocked indicators, etc.

Thanks for the suggestion, we will consider for next major release.

authors: longdenr navneet-g

repo: Microsoft/featuretimeline


text:
Stale mission elements linger around on restart

Steps to reproduce:

create a mission where you place a specific block (in my case one from: ["redstone_block", "emerald_block", "lapis_block", "cobblestone", "gold_block", "quartz_block"] at random) anywhere in the environment,
send quit command to end the mission
redraw the mission with same logic as above
notice that the previous block(s) are not cleared, but they are retained in the environment

If I am supposed to "search" for a specific block, it fails due to other rogue blocks being present.

Have you tried forceWorldReset?
In XML this would likely be forceReset in any Generator.

I send the quit command just before the mission starts, further when I make an API call to forceWorldReset, the mission fails to start and the agent quits.
Am I missing something?
Can you please give an example of forceRest in the Generator? I am not too sure I understood the second line.

@J-F-B-M ok! i managed to figure out the forceReset in the generator from one of the examples.
However, the agent quits with max retries elapsed error.

Well, even on forceReset, the blocks from previous runs remain. (I just had to give a longer time before the mission began to get force reset to work)

Hi @okkhoy, this behaviour is by design - generating fresh worlds in Minecraft is a slow business, so for rapid turnaround between missions we reuse the existing world, provided it matches the requested one. Where we need to reset changes made in the previous mission, we tend to do this by drawing a volume of air blocks in the drawing decorator - this will erase any extra blocks that were placed. Many of the samples use this technique.
The forceReset flag forces creation of a brand new Minecraft world, which should guarantee a clean environment, but adds a considerable overhead to the start of each mission. I'd only use it if the air-drawing is insufficient - eg if the agent has been allowed to mine, etc.
"I send the quit command just before the mission starts" - I'm not sure why you'd want to do this? Sounds like it might be the cause of some of the other issues you are seeing (forceReset not working, max retries elapsed error)?
Am closing this issue but please do open a new one for any other problems you are experiencing.

authors: DaveyBiggers J-F-B-M okkhoy

repo: Microsoft/malmo


text:
Port wildcard import of project extensions from xplat

These extensions will generally come from package management systems by writing to a file named:
$(MSBuildProjectExtensionsPath)$(MSBuildProjectFile)..props
Each package management system should use a unique moniker to avoid collisions.  It is a wild-card import so the order of the import is based on the file system's ordering.
Fixes #784

Included unit tests
Fix tests that broke when BaseIntermedateOutputPath was moved.

Current import order is:

directory build props
project extension props
project extension targets
directory build targets

PORT TO master:
Conflicts:
src/XMakeTasks/Microsoft.Common.props
src/XMakeTasks/UnitTests/Microsoft.Build.Tasks.UnitTests.csproj

👍

@dotnet-bot Windows_NT Build for Desktop please
(race in XSLT test that we've seen acouple of times before)

Pushing since we want this fix ASAP, and the one failure on Desktop was a race and didn't repro on the (on this branch lying) "CoreCLR" build which is identical.

authors: nguerrera rainersigwald

repo: Microsoft/msbuild


text:
[build.pl] Add a -runTestName arg for running specific tests ..

.. this passes the argument to nunit-console -run:$runTestName

Hi @radical, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
We will now validate the agreement and then real humans will evaluate your PR.
TTYL, DNFBOT;

Closing this and raising another PR with an additional change.

authors: dnfclas radical


text:
Please dont review: Using branch for testing : Clean up of OE_USE_LIBSGX

This is purely for experimental purposes. Please dont review

Radhika: You can fire a sandbox run to stabilize your branch before issuing a PR. Trust this helps.

bors try

bors try

Closing experimental pull request and opening an actual one

authors: anitagov radhikaj

repo: Microsoft/openenclave


text:
New repo client API: allow public repositories

The original implementation for 1ES day was specifically targeted at
private only. This aligns with the configuration values in the orgs.

@jeffwilcox,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

authors: jeffwilcox msftclas

repo: Microsoft/opensource-portal


text:
collect network metrics for containers

almost same with #764
This functionality requires job-exporter container to be privileged and has host pid namespace. Since this will have security issue, I enabled admission control in api server with recommended policy and DenyEscalatingExec. @ydye please verify this.
It also requires other service to have non-host pid namespace to be accurate.

fixed #721

Coverage increased (+3.06%) to 57.966% when pulling 155773696db57f6aa25281d96f8ee40df1798d26 on dixu/job-network into 2ccc86d08c7b66f3952170ce86d0d1e16be4b644 on master.

authors: coveralls xudifsd

repo: Microsoft/pai


text:
[AKS] api-server RBAC access for watchdog

As api-server over AKS need RBAC access, make prometheus & watchdog leverage service acccount of K8s to access api-server for this case.
@xudifsd @ydye ,mv the previous reviewd pr to submit to pai/aks

Previous reviewed PR:
https://github.com/Microsoft/pai/pull/1601
Related tracking issue:
https://github.com/Microsoft/pai/issues/1551

Coverage increased (+5.1%) to 56.874% when pulling 6457a0ec475ad7239dbf31028e45ea91a26a334d on yanjga/aks-prometheus into 9938b2b9977ae81250d2c1f204401f87f37e9a16 on pai/aks.

Coverage increased (+5.1%) to 56.874% when pulling 6457a0ec475ad7239dbf31028e45ea91a26a334d on yanjga/aks-prometheus into 9938b2b9977ae81250d2c1f204401f87f37e9a16 on pai/aks.

@xudifsd, @ydye @fanyangCS
Seperate current PR to 2:
1 watchdog api-server access related is this PR
2 prometheus related is https://github.com/Microsoft/pai/pull/1875
will add unified token path after merge to new cluster object model branch

neither Jenkins nor any unit test covers this part of code. we need to test on this PR.

after no issue and approved, will retest it

authors: YanjieGao coveralls fanyangCS


text:
pressing control+L should bring focus to the current directory text box

When you press Control + L in a browser or in File Explorer focus is brought to the URL or current directory. PerfView should do this to.

Is it expected to work only in main window or some other windows as well? I can't imagine one, but maybe I don't see something.

Fixed via #937.

authors: brianrob daklimek ilabutin

repo: Microsoft/perfview


text:
execute stored procs from the interface

SQL Operations Studio Version:

Steps to Reproduce:
right click on stored procedure, only get access to create or alter script, not execute the script itself.

this feature is added to the next release

authors: llali mattcushingAG

repo: Microsoft/sqlopsstudio


text:
Questions about test adapter vs framework versions compatibility when using vstest.console.exe

Hello,

If I have MSTest.TestFramework version X in project, do I have to use the same version for MSTest.TestAdapter?

For example, if I have framework 1.2.0,  do I have to use adapter 1.2.0 too?
Or can I use for example 1.3.0?

Should I specify test adapter as argument to vstest.console, or should it be referenced from tested project?

I am asking because I have downloaded most recent vstest and mstest test adapter (Microsoft.TestPlatform 15.6.0-preview-20171211-02 and MSTest.TestAdapter 1.2.0) and tried using it to run tests which refer to various versions of MSTest framework, with or without adapter in project. There were several issues. I could not reliably run tests:

if I specified test adapter 1.2.0 to vstest, I could run tests in project with mstest 1.2.0 and no test adapter, and in project with mstest 1.1.18 and adapter 1.1.18. But I had errors or no tests were executed for example in project with mstest 1.2.0 and adapter 1.2.0, or in project with mstest 1.1.18 and no adapter, or in project with mstest 1.1.14 and adapter 1.1.14
if I did not specify adapter to vstest, I could run tests in project with framework 1.1.18 and adapter 1.1.18, but it did not work for project with framework/adapter 1.2.0 or 1.1.14

Here are tables which show tested combinations:
Vstest (microsoft.testplatform.15.6.0-preview-20171211-02) with test adapter 1.2.0
| MSTest Framework   1.2.0 | MSTest Framework   1.1.18 | MSTest Framework   1.1.14
-- | -- | -- | --
No MSTest Adapter   in project | OK - tests   executed | Error (2) | No tests   discovered
MSTest Adapter   1.2.0 in project | No test discovered | Error (2) |
MSTest Adapter   1.1.18 in project | Error (1) | OK - tests   executed |
MSTest Adapter   1.1.14 in project |   |   | Error (3)
Errors:

An exception occurred while invoking executor 'executor://mstestadapter/v2': Method 'get_Arguments' in type 'Microsoft.VisualStudio.TestPlatform.MSTest.TestAdapter.Execution.TestMethodInfo' from assembly 'Microsoft.VisualStudio.TestPlatform.MSTest.TestAdapter, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' does not have an implementation.
Could not load type 'Microsoft.VisualStudio.TestTools.UnitTesting.ITestDataSource' from assembly 'Microsoft.VisualStudio.TestPlatform.TestFramework, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Type 'Microsoft.VisualStudio.TestPlatform.MSTest.TestAdapter.MSTestSettings' in assembly 'Microsoft.VisualStudio.TestPlatform.MSTest.TestAdapter, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' is not marked as serializable.

Vstest (microsoft.testplatform.15.6.0-preview-20171211-02) without test adapter
| MSTest Framework   1.2.0 | MSTest Framework   1.1.18 | MSTest Framework   1.1.14
-- | -- | -- | --
MSTest Adapter   1.2.0 in project | No tests   discovered | Error (1) |
MSTest Adapter   1.1.18 in project | No tests   discovered | OK - tests   executed |
MSTest Adapter   1.1.14 in project |   |   | No tests   discovered
Errors:

Could not load type 'Microsoft.VisualStudio.TestTools.UnitTesting.ITestDataSource' from assembly 'Microsoft.VisualStudio.TestPlatform.TestFramework, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.

As a side note, I also checked nunit and xunit and I could basically run tests in projects with various versions of framework and adapters.

@pkruk2  : We apologize for the confusion and inconvenience.

If I have MSTest.TestFramework version X in project, do I have to use the same version for MSTest.TestAdapter?
Yes, both adapter and framework should have same version and should both be installed in test project. We advise to install latest stable version (1.2.0) or beta(1.3.0-beta2).
Should I specify test adapter as argument to vstest.console, or should it be referenced from tested project?
No, you don't have to specify test adapter to vstest.console. It should be referenced by test project itself.

Thank you, using the same version of test framework and test adapter indeed works.
I also checked that it also works with VsTestConsoleWrapper if the project does not have the test adapter installed.

repo: Microsoft/testfx