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.
Related
After going through a windows 10 re-installation due to a windows update crashing my laptop, I was left with re-installing many applications. One of them being node.js. When I tried to install it through the windows installer, I kept getting 'setup wizard ended prematurely because of an error message'. I am not sure what the problem is. I used x64 version which is what my OS is and there is no nodejs folder in program files. When I logged the installation this message popped in a lot of the lines has no eligible binary patches. Before the no eligible lines there were error logs such as:
'WixSchedInternetShortcuts: Error 0x8007000d: failed to add temporary row, dberr: 1, err: Directory_'
'WixSchedInternetShortcuts: Folder 'ApplicationProgramsFolder' already exists in the CreateFolder table; the above error is harmless'
If that is not enough information please advice me on how to send the full logs without spamming huge text in the thread. Thank you.
The MSI log file:
https://gist.github.com/luki2000/ab00476127d54aaf610d8bda84d40a64
Maybe try to search the log for "value 3" as explained by Rob Mensching in his blog. Doing so will find the locations in the log file that describe errors of significance.
Many people use dropbox, gdisk or similar to post logs. Some put it on github (just a sample log for OP, leaving in for reference). Check that last link, is that the same problem you see perhaps? (search for "value 3" as explained above - without the quotes of course). Looks like there is an error creating an Internet shortcut. Perhaps that is a Windows 10 problem? I will take a quick look.
I am betting Bob Arnson knows what this problem is outright. He will probably give us the real answer, see below for my workaround.
The correct thing to do overall, would probably be to communicate the problem back to the Node.js guys so they can fix the problem once and for all.
UPDATE: Maybe see if this answer helps you: node.js installer failing with 'CAQuietExec Failed' and 1603 error code on Windows 7. Essentially un-check Event tracing(ETW) in the setup's feature dialog - or you can try to launch the MSI from an elevated command prompt.
UPDATE: There seem to be two Internet shortcuts configured for this MSI in the WixInternetShortcut table. I would just create a transform to remove these two shortcuts and try a reinstall. If you feel bold and fearless and like to break the law, you can delete the two rows from the table and just save directly to the MSI itself. This is never the right thing to do if you are a deployment specialists. The original MSI is sacred, but if this is for your own system and you need to get something done, that would work. Then you just install the MSI direct afterwards. Otherwise you can install the transform after creating it with a simple command line:
msiexec.exe /i node-v8.11.2-x64.msi TRANSFORMS="C:\MyTransform"
You can create the transform using Orca, InstEd or SuperOrca or any commercial tool that supports creating transforms.
In case you don't know, transforms are little database fragments that are applied to the original MSI (which is also a database under the hood). After the transform is applied the in-memory version of the MSI is the MSI + the changes from the transform.
As of Wednesday, sometime between 2:01 pm and 2:43 pm Eastern, Visual Studio Team Service Release Management began failing in the Azure Web App Deployment Task, during the Deploy Website to Azure step with the generic error:
You cannot call a method on a null-valued expression
We created a new Release Definition, but it exhibits the same issue.
I attempted a Release with the previously successful version of the build, and it too exhibits the same exception.
I have verified that there is no deploy.cmd in the repository.
I have verified the items in the change set for the build.
They only touched one .cs file, three .js files, and changed the value of the <add key="Client.CacheVersion" value="X"> from 4 to 6.
Though the documentation states that the -ErrorVariable is valid for the script in question. The only difference in the log files (pre-failure information) is the addition of -ErrorVariable publishAzureWebSiteError to the end of the Publish-AzureWebsiteProject call.
Is there anyway to either populate the publishAzureWebSiteError, or remove this extraneous variable?
UPDATE:
After adding system.debug. I see that I am unable to resolve {mysite}.scm.azurewebsites.net.
UPDATE II
After 2 hours with Microsoft it appears that Release Management is having some difficulty working with App Service Environments. At first it was unable to map the scm URL appropriately and once we added the expected suffix to the Web App Name field we received the error:
Conflict: The host name MY_WEB_APP.APP_SERVICE_NAME.p.azurewebsites.net is already assigned to another Azure website: MY_WEB_APP.
FINAL UPDATE
It appears that the releases are now running as expected with in at least on the previously failing releases no changes were made. Since MS clearly changed something on their end, this question will provide no benefit to future users. I am voting to close it.
As this question has yet to be closed.
For those that come after:
The fix came from Microsoft. Premier support emailed me with the following this morning:
I just spoke to the developer who pushed the fix. And the fix has to do with correctly forming a SCM name which in your case is part of ASE. So there were no exceptions being raised this time and it worked for you.
So there are/were no workarounds, nor changes even possible on the part of the end user.
I would like to have Visual Studio sign my assemblies.
I got past the point where I can specify my PFX file without any complaints. That was not easy, as I had two of errors. Yes, I had to make sure that I used openssl (a stackoverflow article helped with that error) and a microsoft article helped with the first error message, where I had to import the PFX file, clear/set options, and then reexport to not include downstream certificates.
When I go to build a project, I receive the warning:
Option 'keycontainer' overrides attribute 'System.Reflection.AssemblyKeyNameAttribute' given in a source file or added module"
Naturally, my assembly did not get signed.
I did some research and the best suggestion that I saw was to add a line to the project file (did not help) or to sign stuff manually using a post build event, which I am now doing, but I would still like to get the sign tool to work.
I cannot imagine that Microsoft would offer the Singing tab, if the vast majority of developers would not be able to use the feature.
Heck, with the new Visual Studio 2012 Update 1 release, I would have expected that signing assemblies (DLLs or EXEs) would be child's play. The task is anything but.
Thoughts?
Without more information, I can't tell if this will fix your issue. But I'll post the answer that worked for me. In my case, I had converted an old project (pre VS 2012) that had specified signing in the AssemblyInfo.cs file like so...
[assembly: AssemblyDelaySign(false)]
[assembly: AssemblyKeyFile("")]
[assembly: AssemblyKeyName("")]
I usually use the Signing tab in project/properties as you describe. The warning message was essentially saying "Hey, you already told me something different in the source code!"
The solution for me was to remove the above three lines in the AssemblyInfo.cs file.
I realize this is probably way after your original post but I hope someone finds it useful.
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").