I am trying to test my Dialogflow app on Actions on Google.
I managed to release one alpha version without a problem but now when I try to release the second version it gives an error
Testing instruction not found.
And then nothing happens. I couldn't find this error anywhere, neither does it take to some dialog to fix it.
What does this mean and how was I able to create one alpha version for the same project without error?
For those who are not finding the Testing Instruction section in Advanced Options > Account Linking menu, you can find it under:
Deploy > Directory Information > Additional Information > Testing Instructions
Reference
As we determined in the comments, you added account linking in your second version. When you add some sort of account linking, you need to give directions to the review team so they can fully test the capabilities of your actions. This should be stated in the Testing Instructions section at the bottom of the account linking section.
Related
I'd like to add a Quick Look extension to my program, but in order to be useful, it would have to access the Core Data stack, which seems to require me to add an App Group and a provisioning profile to the project.
Until now, it has been possible for anyone to download the project from Github and compile and run it out of the box. All project targets are set to Team: None and Sign to Run Locally. If I add my provisioning profile to the project, this will no longer work. They will have to create and add their own provisioning profile and change the Signing & Capabilities settings on each of the 26 targets (there seems to be no way to do them all at once). And the profile will have to be renewed every year.
My question is, is there any way around this? Is such a major change really necessary for what amounts to accessing a file inside the program's own bundle (and another in its Application Support folder?)
EDIT: As was pointed out to me on the Apple Developer forum, you don't need a provisioning profile as long as you prefix the group name with the development team identifier. This still won't make it build out of the box, though. You will still need a developer account and set a team on every target.
I had missed that you are supposed to have a team identifier as the prefix for the group name. That still doesn't solve the problem that my project will no longer build out of the box for anyone who downloads it from Github, but it answers the question asked in the subject line.
I tried to google. Microsoft Connect doesn't accept bugs for Service Bus. Azure Portal sends to either MS forums or to StackOverflow - so here I am.
The question is really in the title: how do I report a bug with Service Bus?
(not the Azure version, but the one you install on premises)
And here is the issue:
Microsoft.Cloud.ServiceBus.dll has a reference to Microsoft.Cloud.Common.AzureStorage.dll. It uses one type from that assembly - namely, StorageAccountInfo. It's part of a configuration section (namely, NamespacePolicyDataStoreFactorySection.Parameters.BlobStorageAccountInfo), but apparently only makes sense in the Azure environment, and never used in the on-premise scenario.
But here's the catch: Microsoft.Cloud.Common.AzureStorage.dll is not actually shipped with Service Bus 1.1. I tried to find it in various SDKs and Azure toolkits, samples and whatnot (of which I have plenty), as well as online - and found zippo information about that DLL or where to get it. This is the only place I found a mention of it.
Despite being a WTF in itself, the absence of DLL does not really prevent anything from working: the type is not actually touched by any code in the on-premise scenario, so no complaints.
But here's the second catch: mscorlib.dll v4.6.7.0 (which came with VS2015 CTP5) has a slight change compared to the previous version, 4.0.30319.34014, - in System.Attribute.InternalGetCustomAttributes(PropertyInfo,Type,bool), more precisely, this line. That line did not exist in the previous version of mscorlib, and everything was fine. But now it does exist, which leads to the property type being touched, which leads to loading the DLL, which fails, because DLL is not there.
So the whole process starts with loading configuration section NamespacePolicyDataStoreFactorySection and works like this:
ConfigurationManager.GetSection ->
... ->
BaseConfigurationRecord.GetSectionRecursive ->
... ->
BaseConfigurationRecord.CallCreateSection ->
MgmtConfigurationRecord.CreateSection ->
ConfigurationElement.Reset ->
ConfigurationElement.get_Properties ->
ConfigurationElement.PropertiesFromType ->
ConfigurationElement.CreatePropertyBagFromType ->
Attribute.GetCustomAttribute (for property BlobStorageAccountInfo of type StorageAccountInfo) ->
... ->
Attribute.InternalGetCustomAttributes(PropertyInfo) ->
Attributes.GetIndexParameterTypes ->
RuntimePropertyInfo.GetIndexParameters ->
... ->
RuntimeMethodInfo.GetParameters ->
... ->
kaboom! (touches the return type, tries to load DLL containing it, fails)
Some (futile) attempts at a workaround
Remove the configuration section from config. Unfortunately, Service Bus is not very fault tolerant in this respect: fails with NRE when section is not present. It is also impossible to provide an alternative config section "handler", because in the .NET config system "handler" and "data" are the same thing.
Provide a fake DLL with the needed type. Can't do that, because everything is strongly named.
Find the missing DLL somewhere. Tried that and failed. There are no mentions of the DLL on the web, let alone the bits.
A careful reader may ask: whoa, wait a minute! VS2015 CTP5?! Are you saying you installed pre-release software on a working machine?! Well then, of course it doesn't work, what did you expect? That'll teach you to be the early adopter!
And the careful reader would be absolutely correct: totally my fault, I knew potential dangers, I did it anyway, serves me right.
But that's not the point. My installing pre-release software doesn't diminish the WTFness of referencing a DLL, but not shipping it. While I personally will be fine, I just want to make sure this doesn't suddenly stop working when .NET 5 is released and hits Windows Update.
I know it's a late answer to the question and it is actually not the answer to the question asked, but today, after installing VS 2015 RC on a PC with Windows Service Bus 1.1 and restarting the PC, my service bus gateway service stopped working and I went through all the pain described in this question but finally could make a solution out of the fake assembly scenario. Here's the solution:
Created the fake assembly Microsoft.Cloud.Common.AzureStorage.dll with version 2.1.0.0 and signed it with a new key file.
Disassembled it using: ildasm /all /out=azurestorage.il Microsoft.Cloud.Common.AzureStorage.dll
Extracted the public key and public key token from another Microsoft.Cloud.* assembly located in service bus folder by ildasm /Tp Microsoft.Cloud.Common.Diagnostics.dll
Opened azurestorage.il in a text editor and changed the public-key token and public key with the ones extracted in the last step
Reassembled the il file: ilasm /dll azurestorage.il /out=Microsoft.Cloud.Common.AzureStorage.dll
Registered the assembly for signature verification skipping using: sn -Vr Microsoft.Cloud.Common.AzureStorage.dll
Installed the resulting assembly to GAC: gacutil /i Microsoft.Cloud.Common.AzureStorage.dll
and it finally worked. Hope this helps anyone who got stuck in this problem.
As given in this answer by Jafin there is fortunately an official fix from Microsoft release 10/23/2015 that solves the issue with .NET 4.6.
Download here: Update for Service Bus Server 1.1 (KB3086798)
as I understand what you need is reporting a bug to Microsoft, and I found out you need to report a bug to Microsoft. Its good to know microsoft will aapriceate users who report bugs.
According to Microsoft answer you can reporting Microsfot bugs here:https://connect.microsoft.com/
note: You must have an microsoft account, you can make it at hotmail.com
And I know some of microsoft products are not there like outlook.com
First go to https://connect.microsoft.com/ :
STEP BY STEP
i.stack.imgur.com/CewDL.png
Step 1: Write the program what you like to report a bug about it, and then click on join.
i.stack.imgur.com/pJbQY.png
Step 2: Click on continue.
i.stack.imgur.com/cCgXq.png
Step 3: Make up your profile.
i.stack.imgur.com/PVqXi.png
Step 4: Click on feedback.
i.stack.imgur.com/nL5Kr.png
Step 5: Write the bug title on text box at the end of page.
i.stack.imgur.com/gEOJG.png
Step 6: Then click on submit feedback
i.stack.imgur.com/MQgV0.png
Step 7: Now you can write the problem and tell Microsoft about this bug.
When I try to run codecoverage tool on release bits of my website I get an empty .coverage file containing the following error:
Empty results generated: No binaries were instrumented. Make sure the tests ran, required binaries were loaded, had matching symbol files, and were not excluded through custom settings. For more information see http://go.microsoft.com/fwlink/?LinkID=253731
This issue does not occur if I run it on the debug version of the same build.
These are the exact steps I perform:
- start monitoring code coverage on IIS server
codecoverage collect /IIS /session:test /output:test.coverage
- perform a few click around the website
- stop monitoring code coverage
codecoverage shutdown /session:test
Note! I do hae the .pdb files in the same place as the binaries.
Any ideas?
Thanks,
Cristina
I finally managed to get to the bottom of this. For the release build, there were 2 things I needed to change in the .config file
specify the path to the Symbols (apparently this is needed even if the .pdf files are in the same location as the dlls)
I had to remove the default exclusion list since these included Microsoft public key tokens and our product is a Microsoft product.
Hope this will be helpful for others running into the same situation.
Regards,
Cristina
Try this: Enabling Profiling.
[UPDATE 5 Jun 2013 14:04:00-04:00 UTC]
I also found this article that you may be interested in: Application Analytics: What Every Developer Should Know.
As far as Code Coverage is concerned, I didn't see anything specific to using the VS Code Coverage tool and configuring for IIS. I did see lots of articles about testing web applications in general, some of which involved setting up code coverage (Setting Up Machines and Collecting Diagnostic Information Using Test Settings being an example).
Sorry I couldn't be of more help to you.
I have a 3rd party web page screen capture DLL from http://websitesscreenshot.com/ that lets me target a URL and save the page to a image file. I've moved this code into my Azure-based project and when I run it on my local sandboxed dev box and save to the Azure blob, everything is fine. But when I push the bits to my live server on Azure, it's failing.
I think this is because either MSHTML.dll and/or SHDOCVW.dll are missing from my Azure configuration.
How can I get these libraries (plus any dependent binaries) up to Azure?
I found the following advice on an MSFT forum but haven't tried it yet. http://social.msdn.microsoft.com/Forums/en-US/windowsazuredevelopment/thread/0344dcff-6fdd-4479-a3b4-3e89750a92f4/
Hello, I haven't tried mshtml in the cloud. But generally speaking, to
use a native dll in a Web Role, you add the dll to the Web Role
project just like adding a picture (choose add existing items). Then
make sure the Build Action is set to Content. This tells Visual Studio
to copy the dll file to the output package.
Also check dependencies carefully. A lot of problems related to native
code are caused by missing dependencies, such as a particular VC++
runtime dll.
Thought I'd ask here first before I burn a day or two on an unproven solution.
EDIT #1:
it turns out that our problem was not related to MSHTML.dll or SHDOCVW.dll missing from the Azure server. They're there.
The issue is that by default new server instance have the IE security hardening feature enabled, and this was preventing our 3rd party dll from executing script. So we needed to turn off the enhanced IE security configuration settings. This is also a non-trivial exercise.
In the meantime, we just created a server-side version of the feature on our site we need to make screen captures from (e.g. we eliminated JSON-based rendering of UI on the client), and we were able to proceed.
I think the solution mentioned in the MSDN forum thread is correct. You should put them as part of your project files, so that the SDK will package and deploy them to the VM on the cloud.
But if they are COM and need to be registed you'd better call the register command via the Startup feature. Please check http://msdn.microsoft.com/en-us/hh351539
HTH
I have recently upgraded to the new Azure SDK (September 2011 v 1.5).
Ever since I have not been able to start the compute emulator. Consequently I can't debug the services on my local machine.
I have seen a suggestion that the problem lies with the fact that my user account has a space in it, so I renamed my account but that didn't make any difference. It may be that the problem is that my user profile path has a space in it. Changing the account name has no effect no the profile path.
On the msdn forums it was suggested that I remove *:808 binding in IIS Manager for Default Website. See MSDN Forums
Anyone have any other ideas?
Another option:
So, given the "rename your user account/regedit doesn't work for you, you may want to look at this MSDN article, which suggests you can just set an environment variable and run the emulator without mucking with the registry... not sure if setting the environment variable globally would let you run automatically within VS.NET without manually starting up the emulator the first time, but it is certainly easier.
Yes, the space(s) in your profile path are the issue, and this appears to be a regression for a bug that was found in a previous version of the emulator (the only reason I even thought to try logging in with a different account in the first place). I was literally just putting together a quick blog post here describing the same issue. You'll need to do some registry editing to fix all the references to your old profile path if you want to fix it, or just create a new user if you can deal with re-installing software (I love the Web Platform Installer, but I found out during this exercise that it doesn't do a good job installing for "all users").