Release action stuck in "Pending" status for hours - ms-release-management

I have tried a release using webdeploy and release management for visual studio 2013. Configured the release based on the steps in http://www.colinsalmcorner.com/post/webdeploy-and-release-management--the-proper-way .
When i started release, it is showing "Pending" status for hours. Don't know what is happening. How i can find the real issue behind this? Is there any detailed log or any debugging methods in release management..??
I am new to release management, please help me....!!!!

My RM license was expired and it was not showing any warning messages on the expiration. When i restarted "Release Management Monitor" service, it was showing license expired..!!!
I reinstalled RM and the issue has been resolved...!

I got the same issue, then I solved it removing all items from Release Template and adding them back afterwards.
Posted here about:
https://fabiostawinski.wordpress.com/2015/03/25/release-management-stuck-on-pending-statusbug/

For me, #DanielMann 's comment about restarting the Microsoft Deployment Agent service on the target server was the solution.

Related

"Failed to load resource: net::ERR_HTTP2_PROTOCOL_ERROR" for React app after upgrading to Visual Studio 2019 16.10.0

After upgrading to VS 16.10.0 (and then 16.10.1) Community Edition a React website no longer runs w/in Visual Studio/IIS Express. The exact same code was just deployed to an Azure app service and works correctly.
The home page is blank and the following error is displayed in the Chrome (Version 91.0.4472.77 (Official Build) (64-bit)) debugger console
"Failed to load resource: net::ERR_HTTP2_PROTOCOL_ERROR"
The solution consists of:
C# class library (.NET Core 3.1)
C# Web API (.NET Core 3.1)
React website
I have tried the following:
Cleaned and rebuilt solution
Cleared browser cache
Uninstalled and re-installed Visual Studio
Upgraded Visual Studio from 16.10.0 to 16.10.1
Ran npm run build which ran with no errors
Additional Note: I was able to restore a virtual machine w/ Visual Studio 2019 v16.9.4 instead of v16.10.1. Then step by step I installed the latest Windows updates and the exact code base. The site runs correctly in v16.9.4. So the problem seems to be in Visual Studio v16.10.0/v16.10.1
Go to the VS Developer Community and up vote this problem
https://developercommunity.visualstudio.com/t/Failed-to-load-resource:-net::ERR_HTTP2_/1446262
This error was driving me nuts too. Windows 10 was updated 2 days ago and I also updated Visual Studio to version 16.10.1. After that, I got the errors, images, CSS not loading correctly.
As SpeedOfSpin mentioned in a comment in a previous post, uninstalling KB5003637 worked instantly for me, no more errors! Everything loads perfectly now.
It wasn't necessary to go back to an earlier version of Visual Studio, it seems it was Windows OS related.
#SpeedOfSpin: Thnx a lot! :)
UPDATE ON ISSUE 1
Today there was a new update KB5004476, I don't see the previous KB5003637 anymore here. KB5004476 is causing the same errors. When installed I get the exact same error "Failed to load resource: net::ERR_HTTP2_PROTOCOL_ERROR", uninstalling solves it instantly again.
I have asked the Microsoft forum what is going on here:
https://answers.microsoft.com/en-us/windows/forum/windows_10-networking/kb5003637-and-the-new-kb5004476-gives-error-failed/db2f2f73-7f5c-477a-b212-5f13c998a09a
UPDATE ON ISSUE 2
As they couldn't provide a solution in the first MS forum (previous link), the same question has been asked here:
https://learn.microsoft.com/en-us/answers/questions/440339/kb5003637-and-the-new-kb5004476-gives-error-34fail.html
Updating Visual Studio to version 16.10.2. doesn't solve the issue either.
UPDATE ON ISSUE 3
After some more testing, it seems it affects the browser Chrome only (As I only use Chrome, as most people do). In Firefox, Edge, and IE it seems I'm not having this issue. It was confusing as I tried so many things and the only solution I still have is uninstalling the KB5003637 or the new version KB5004476. So I guess something is wrong with Chrome after all. For now, I will keep the updates uninstalled, I don't feel like changing my preferred browser.
UPDATE ON ISSUE 4
It is indeed not a Chrome-only issue, sorry guys. Saw the same error in Edge this morning too. It took a long while to recreate the problem, while in Chrome I have it every single time. :(
UPDATE ON ISSUE 5
As asked in the first post here by ChrisP, go to the VS Developer Community if you experience this issue too, and please upvote this problem.
I asked the question there also, but still no solid solution at this point.
https://developercommunity.visualstudio.com/t/Failed-to-load-resource:-net::ERR_HTTP2_/1446262
UPDATE ON ISSUE 6
Two days ago after 1 single refresh (F5), when testing my web application, aside from the HTTP/2 errors, I also had the same blue screen like people are starting to mention. It showed the error "System Thread Exception not Handled" in file "HTTP.sys" and restarted, amazing!
Also, 2 new updates were installed KB5003690 and KB5003537, but nothing changed, I still have the annoying errors. Previous updates KB5003637 and KB5004476, where it started to go wrong, are gone here.
Uninstalling these updates as a workaround isn't the best solution for me, as they get reinstalled when wanting to update Windows 10 (No option anymore to exclude/hide the updates).
For me the easiest/quickest workaround at this point, to test locally with no “Failed to load resource: net::ERR_HTTP2_PROTOCOL_ERROR” errors, no "System Thread Exception not Handled" BSoD! error and most important no stress anymore :), is disabling SSL in the debug settings of your project in Visual Studio. (Right-click Project, Properties, Debug, Web Server Settings below).
Hope this gets fixed quickly!
UPDATE ON ISSUE 7 (SOLVED!)
Microsoft finally released a fix that works for me, more information here (last post):
https://developercommunity.visualstudio.com/t/Failed-to-load-resource:-net::ERR_HTTP2_/1446262?viewtype=all
Installing the most recent update KB5004237 solves the problem in my case. No more "Failed to load resource: net::ERR_HTTP2_PROTOCOL_ERROR" errors, no more “System Thread Exception not Handled” error so far too!
I tried everything including rolling back updates and a full reinstall of Windows. Finally, a Microsoft support rep posted a workaround for this that involves disabling HTTP2. This seems to have worked for me as a temporary solution. In summary:
Start the Windows Registry Editor
Navigate to the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters
Add 2 new REG_DWORD values, EnableHttp2Tls and EnableHttp2Cleartext,
to this registry key
Set both values to 0
Reboot the machine
The rep notes:
The registry values disable HTTP/2 on the machine. You can remove those values when the fix to https.sys is published.
We had the same issue on only the machines that had that KB5003637 installed. We uninstalled it and everything was fine. We decided to upgrade to .net 5 in the end which fixes the issue as it was fairly painless for our projects.
If you can't upgrade try disabling HTTP/2
serverOptions.ConfigureEndpointDefaults(lo => lo.Protocols = Microsoft.AspNetCore.Server.Kestrel.Core.HttpProtocols.Http1);
Mine looks like this for .net core 3.1
public static IHostBuilder CreateWebHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.ConfigureKestrel(serverOptions =>
{
serverOptions.Limits.MaxRequestBodySize = int.MaxValue;
serverOptions.Limits.MinResponseDataRate = null;
serverOptions.ConfigureEndpointDefaults(lo => lo.Protocols = Microsoft.AspNetCore.Server.Kestrel.Core.HttpProtocols.Http1);
})
.UseStartup<Startup>();
});
}
Disable the SSL from the project properties it will automatically down to http/1 and then enable the javascript debugger for the browser
Hope this will help
In my case it was ASP.NET Core Identity that caused the trouble: I had too many roles (user claims) which were stored as session cookies in my browser and caused a "HTTP 400 Bad Request - Request header too long" error. This was showing as HTTP2 protocol error in Chrome and SSL certificate error in Firefox since I was using HTTPS redirection.
In my case it was actually a HTTP Error 400 - The size of the request headers is too long, but I kept getting this ERR_HTTP2_PROTOCOL_ERROR message instead.
In order to find out the real error message, I had to disable HTTP/2 in IIS(right click your site in IIS, open Edit Bindings, double click your HTTPS binding and check Disable HTTP/2).
After fixing the HTTP Error 400 I could enable HTTP/2 again and it worked correctly.
I found that disabling SSL (which I think results in IIS Express dropping down to HTTP 1.1) is a workaround.
this issue (on iis express) on only the OS that had that KB5003637 installed.
if you unable delete this update first upgrate windows 10 to last by
https://www.microsoft.com/en-ca/software-download/windows10
then you can delete kb5003637
(don't forget disable windows auto update)
I got this error creating a new blazor app vs2019/windows10 update to latest versions.
After looking at a prior working blazor project Startup.cs I fixed by commenting out //app.UseHttpsRedirection();
I think this maybe a new project template problem
In my case, upgrading the project to .Net core 5.0 (as #SpeedofSpin suggested) did not help - I had the same issue.
Disabling SSL (as #samejeep suggested) for application was demanding, because my projects uses IdentityServer4 and it just stopped authenticating after that - so I didn't continue that path.
But as a workaround I have changed all requests for css, js, and static files via non-SSL http:// requests.
So for example, instead of this
<link rel="stylesheet" href="~/css/site.css">
Which would use the current request's protocol https://, I've used absolute paths, e.g.:
<link rel="stylesheet" href="http://localhost/css/site.css">
Note, that I'm stating "http" (not "https") explicitly.
I did that for css styles and js scripts and that was enough for me.
I didn't have to do it for images though.
For me this is just a dirty workaround (I'll be waiting for MS to release a patch), but at least it allows me to keep doing my work.
Update:
I've found a better way to disable HTTP/2 via registry on my localhost and that solves the problem too.

SQL Server 2017 installation is stuck

For some reason I can't get SQL Server 2017 installed on my Windows 10 machine.
First thing to do with this buggy installer is that I had to uninstall VCRuntime 2017 in order for the installer to work.
And now, the installer is stuck at this point exactly every time I try to install it:
What I've tried so far:
Killing msiexec process
Running the setup with additional parameter as mentioned here
Setup.exe /SkipInstallerRunCheck
Restarting ... reinstalling ... turning off anti-virus ...
[Solved]
The problem was due to a background download that was taking forever especially on a low internet speed (i.e. python or R-support component).
[Solution]
If you really need python or R-support just wait until download is complete
Else, deselect python and R-support from the component list.
(or) kill the child process for python or R-support component downloader from task manager.
UPDATE:
The actual problem turned out to be the R-support component(s) slowly downloading in the background locking up the installation GUI
with no notification or warning show to the user as to what is
actually going on.
So it seems this "locked install problem" can be caused by installing several different components, at least by Python or R-support. As mentioned below, please check any available logs or event logs for clues.
In summary, options:
Maybe try to unselect such components for install if you do not need them.
If you need the components, leave the setup to complete, and check progress in log files as explained below. Verify Internet access (proxy?).
Stuck Download?
UPDATE: Did you see this blog? Looks like the setup tries to download and install the Python runtime, and this can take forever. Are you behind a proxy btw? No direct connection to the Internet? If so I suppose this could also cause further problems. Probably not the cause, but worth a mention.
Apparently you can check the following log file for progress for the installation:
%ProgramFiles%\Microsoft SQL Server\140\Setup
Bootstrap\Log\DATE_TIME\RSetup.log
DATE_TIME in the above path must be converted to your valid values. For example: 20170804_162723 (date part and time part).
See this answer as well: SQL server 2016 installation freeze. You could also try the suggestion to deselect all components you do not need to prevent any background downloads?
General Debugging
Leaving in the general purpose debugging suggestions below.
Generic Advice: From experience I would create a new local admin user and try to install using that account. This is to avoid any "unclean" or special conditions that have occurred in your user profile or registry during regular Windows use. Might not do much, but sometimes it gets the job done with surprising ease. Worth a try I think.
Some Further Things: I wrote up a little check list a while back, I'll add it and see if it inspires some new ideas that can help you. See under "Core Deployment Problems". That first "check list" was condensed from a longer and somewhat excessive first writeup - one of those answers that unintentionally turned into a blog and maybe a hard one to read.
Logging: Did you check log files and / or event logs properly for clues as to what is happening? I find the best approach for deployment to enable logging for all MSI installations. The performance hit it triggers is minuscule compared to the benefit of having a real log-file always available when you suddenly need one. You can enable logging for all MSI files as explained on installsite.org (section: "Globally for all setups on a machine"). MSI log files will then just sit in your %TEMP% folder after installation. They have a random hex name, and you can flush them all regularly if you do not need them. You sort by modify date / time to find the latest one(s) created - obviously.
Jedi trick: You will want to go home and re-think your life if you don't enable logging for all MSI files. Moral of the story: MSI log files are cool. They are very verbose, but they are beautiful. There are some hints on interpreting them here (bottom).
My 2 cents: SQL Server Installer consists of several small MSI installers. MSI installers can only be installed one after each other (as fas as I know). In my case, I launched another MSI setup while installing SQL Server. This caused SQL Server Setup to hold until I finished the concurrently running setup.
So, at least in my case the problem was self-made.
You have to remove configuration settings for SQL Server from Windows Registry editor.
Sql server
2017
VS

Google App Engine Error: DNS lookup failed for URL: http://metadata.google.internal

I've been working on a small Google App Engine (standard environment) project that uses Cloud Endpoints v2. My code is largely based on the quickstart provided by Google.
Everything was working fine, but I re-deployed today after having not looked at it for a few weeks, and I'm getting the following error when I attempt to call the endpoint:
error: An error occured while connecting to the server: DNS lookup failed for URL: metadata.google.internal
This wasn't happening before. It seems to be happening when the endpoints package is being imported by Python.
My endpoint doesn't do anything fancy - I haven't changed the source from the sample EchoApi. The error ends up in the GCP Logging console no matter if I try to access the API through the API Explorer or via Curl.
I don't get any errors during deployment.
Edit #1
Some further information:
The error originates from within Google's code that is included with the google-endpoints package which I've included in my lib folder, per
the documentation. Specifically, the error occurs on line 54 of google/api/control/wsgi.py.
Basically, it's making a request to metadata.google.internal using urllib2.
I'm guessing this address is only available from within the Google Cloud, and that for whatever reason, the instance that's hosting my app can't do a DNS lookup on it.
Edit: #2
Dug a bit further.
It seems that the error originates in the google-endpoints-api-management package. Changes committed to that package on October 19th seem to have introduced additional platform reporting. metadata.google.internal is queried to check if the code is running within the Google Container Engine, then it blows up, because the metadata address doesn't resolve.
Here's the commit:
https://github.com/cloudendpoints/endpoints-management-python/commit/0a37d0e443091053ed03e455e06d3a0ae770999f
The google-endpoints package only requires google-endpoints-api-management >=1.0.0b1. On my end, things were working fine on version 1.0.0b2, but then I built a new lib folder, which brought down 1.0.0b5, and things went sideways. Required packages haven't changed between b2 and b5, so I'm thinking I may be able to just downgrade back to b2 for the time being. Haven't tried it yet.
Sent the Google Dev an email. Perhaps he'll chime in with further tips.
Edit: 2016-11-07
Tested downgrading the google-endpoints-api-management package to 1.0.0b2. Seems to be working, kludgy a fix as it is. If you're using the lib folder, the following will scrub the newer error-prone wsgi.py file and put back the older one:
pip install -t lib google-endpoints-api-management==1.0.0b2 --upgrade
Not pretty, but it may just get you back in business.
On a side note, the Google engineer promptly replied saying that he would take a look at this issue soon. With luck, endpoints v2 will eventually come out of beta, 'cause I'm really liking it so far.
This will be fixed in an upcoming patch to the google-endpoints-api-management package (which will be 1.0.0b6). It will probably be released sometime on Monday, 11/6.
If you'd like to continue testing right away and this error is blocking you, you can go back to 1.0.0b4 until 1.0.0b6 comes out. Everything should still work as normal with that version.
Thanks for bringing this to our attention! We're doing our best to iron out all of these wrinkles now during beta in preparation for our first general release.
EDIT: 1.0.0b6 has been released and resolves this issue. Thanks for your patience during our beta phase!
(Posted solution on behalf of the OP).
Google has released version 1.0.0b6 of the google-endpoints-api-management package to address this issue. It solved the problem for me. For anyone who is encountering this problem, clean out your lib folder and re-install the google-endpoints package. This will bring down the new google-endpoints-api-management package with it.
Thanks to Brad at Google for really quick action on this.

Sudden failure in DNN development environment

I've been working on a mixed desktop-and-web based solution for quite some time now. My local development environment was using VS2013-Pro, a recent DNN version (7.3, I think), Webmatrix 3, IIS Express 8.0, and SQL Server 2014 running on Windows 7 on Parallels on my Mac. Everything is up-to-date, all SP's installed, etc.
I developed a couple of REST webservices and a DNN module, and it's all been humming along and working really--shockingly--amazingly(!) well, when very suddenly:
I hit the DNN site and Webmatrix crashes and I get an error that says "IIS Worker process has stopped." And hasn't worked since. The debugger gives me the message "Unhandled exception at 0x762CC42D (KernelBase.dll) in iisexpress.exe: 0xE0434352 (parameters: 0x80131530, 0x00000000, 0x00000000, 0x00000000, 0x72F90000)."
I did not change anything, this started in the middle of a coding session. It worked fine for months, and then it just didn't any more.
I researched a bit and found several suggestions, none worked (delete cache folder, uninstall/reinstall). I find another post that mentions that Webmatrix is a dead product now. I try just to set up same site in IIS (following DNN's own instructions and a couple of other very similar sets I found). Still can't make site load--even the front page.
I download a fresh DNN install package (7.4 now) and try from scratch. Now when I try to load the site I get Visual Studio's Just In Time Debugger telling me an unhandled Win32 exception in w3wp.exe [2648]. I try running the debugger but it doesn't actually give any information.
I feel like other than the Webmatrix/DNN installation I've always had a lot of trouble getting DNN running locally, even following the directions to the letter. I need it running locally because I work disconnected a lot.
Am I missing something big here? Is anyone else having trouble all of a sudden? I've spent the better part of 4 days unistalling, reinstalling, tinkering, and can come up with nothing.
-Tim
OK, so after uninstalling everything (down to the metal, everything to do with SQL server, IIS, Webmatrix, and the recent .net framework updates) and then reinstalling them, I've been up and running for a week or so now. I've disabled Windows update, I think it was something in there that got me in this position in the first place. Not a great long-term solution, but it'll do for now.

TSD3004 error with Visual Studio 2008 Database Project

I am using Visual Studio Team System 2008, version 9.0.30729.1 SP. I have a database project that I was working with yesterday with no issues - I was able to build and deploy the database successfully. Today, however, when I open the solution I receive what is listed as a "Warning" that halts any Build/Deploy/etc process, but cannot be suppressed via the Project Properties page.
The Warning reads: "TSD3004: The application encountered an unexpected error. To diagnose this problem, enable tracing. You should contact product support."
I did contact Product Support, but they insist I pay for someone to help me get this fixed. There are zero records returned from an search of "TSD3004" on either MSDN or support.microsoft.com, and there are only three returned from a Google search (all irrelevant).
Can anyone please help me figure out what's happening?
Have you tried asking on Microsoft's dedicated forum?
http://social.msdn.microsoft.com/Forums/en-US/vstsdb/threads/
Actually I guess you did.. :)
http://social.msdn.microsoft.com/Forums/en-US/vstsdb/thread/eea24181-e115-4f56-a482-58059160d705

Resources