When I have the AWS Toolkit installed, it takes a long time for Visual Studio (2015 update 2) to open.
Why? Because (as I saw using Fiddler) it's posting to 169.254.169.254/latest/dynamic/instance-identity/document like 9 times, and timing out every time.
I found this article which explains what that's all about.
But how do I turn it off? I really don't want to wait for so long for Visual Studio to load every time I open it.
The underlying SDK that the toolkit uses had a bug, fixed last week, where it was attempting to always fetch instance metadata to try and determine the AWS region (even when not running on an EC2 instance). I don't recall the version of the toolkit being built on that SDK version but it's possible.
A colleague posted an updated toolkit (1.9.6.21) this evening for an unrelated change - can you install this and see if you still see an issue? If so I'll take a look when I get into the office.
Related
Since the update before last to AWS Toolkit, when running Visual Studio 2022 with AWS Toolkit installed and enabled, the entire PC grinds to crawl.
Specifically, physical memory use shoots up to 99%, there's a huge amount of continuous disk activity and CPU use rises to around 50%. This renders the entire system completely unusable (think, two minute delay between clicking and something happening). Oddly, nothing appears in the process list in Task Manager that accounts for either the levels of memory or CPU use. It feels like a monumental memory leak but really I've no idea what's going on.
I've tried completely uninstalling and reinstalling VS and uninstalling, deleting the AWS Toolkit folder in "Users...etc." and reinstalling the Toolkit. Everything is fully up-to-date.
As I say, this has happened since the update before last. It's strange that it isn't mentioned anywhere that I can find on the internet and it's difficult to imagine that such a serious issue would only happen to me.
So, has this happened to anyone else and does anyone have a fix? I wanted to raise a support case on AWS Console but I only have a basic account so am unable to do so.
This issue has been resolved (see https://github.com/aws/aws-toolkit-visual-studio/issues/314#issuecomment-1401060605 for more details).
The system in question is running Windows 7. At some point .NET 7 was installed onto it (possibly as a result of a Visual Studio update). .NET 7 does not support Windows 7, and dotnet publish commands started to produce internal errors, and is taking a long time to complete. The AWS Toolkit's Lambda publishing features are built on top of the dotnet CLI commands, which is how the degradation was noticed.
This can be mitigated by installing an older version of .NET (like .NET 6) and telling the dotnet tooling to use a specific version of .NET instead of the latest detected version.
From https://learn.microsoft.com/en-us/dotnet/core/tools/global-json:
The global.json file allows you to define which .NET SDK version is used when you run .NET CLI commands. Selecting the .NET SDK version is independent from specifying the runtime version a project targets. The .NET SDK version indicates which version of the .NET CLI is used.
Add a global.json file to the same folder as your project or solution with the contents shown below, referring to the .NET SDK version you want to use (the example below uses 6.0.300)
{
"sdk": {
"version": "6.0.300"
}
}
Sagemaker Studio worked flawlessly for me for the first 6 months. Then I started observing this issue. Screenshot of the error message
The screen holds up at this stage forever. Here's what I have tried:
Clearing my cache, even using a different machine. So I don't think the issue lies with the browser or my machine.
Pressing 'Clear workspace' in the screenshot above.
Shutting down all the apps in my sagemaker domain (excluding the 'default' app). This used to work initially but now this has stopped working all-together.
Created a new sagemaker domain with fraction of the files in the previous domain. Still, I see the same error message in the new domain as well.
This is severely affecting my work and I can't find a solution for this anywhere on the internet.
I've seen this issue before. Restarting the JupyterServer app and clearing out the EFS storage attached to your Studio domain helps.
Also, it is worth checking the JupyterServer logs to see what is causing the issue. Additionally, please make sure to use the latest version of Studio.
We have submitted a UWP app, built using the Windows 8.1 SDK, to the Windows Store, published with the 'Private Audience' option. We observe that LoadListingInformationAsync (in the CurrentApp class) throws a 0x80190194 Not found (404) exception.
This happens regardless whether we run the project in Visual Studio or whether we install the Store version. The In-App products have been added, published and are all marked with 'In The Store'. We have checked that all the identifiers/names listed under 'App management/Identity details' match those in the manifest. We have checked that the In-App-Code works as expected with the CurrentAppSimulator. We have also used a network traffic monitor to check for network errors and haven't found any.
We have posted the same issue in the windows forum where it was suggested by a Microsoft employee to simply wait a couple of days. It is now two weeks since our in-app-products were published in the dashboard. This problem is blocking us completely and we definitely need help in fixing this issue.
Therefore we would very much appreciate if someone at Microsoft could find out why the in-apps published in the dashboard apparently haven't been installed correctly in the store and thus aren't visible from our application.
Here is our Package SID:
S-1-15-2-2762217728-2497590674-2702625719-1901796822-1169495103-2187450542-4267134542
I've been using a Windows 2008R2 EC2 instance for some time. As of today, it still works. I started working with the AWS API, and I was unable to start my instance using the API, the error message being "not authorized for images", specifically : An error occurred (AuthFailure) when calling the RunInstances operation: Not authorized for images: [ami-088dab1e]
That's when I learned about deprecation.
From what I read, what this means is that the AMI being used is no longer publicly available. When using the API call "describe-images", this image cannot be queried. While it apparently can still be used from the console, the API simply doesn't support it and will not start an instance using that image ID. On the console, the AMI description reads : Cannot load details for ami-088dab1e. You may not be permitted to view it.
I understand how to find a new image and I think I understand how to launch my instance using a new image. However, I have lots of custom software installed on this instance. So before I try it, I want to know if I will lose that custom software installation if I launch my existing instance with a new AMI. I'm hoping that my custom software won't change, but I'm skeptical. I don't want to fire up a brand new version of Windows and start from scratch. Mostly, I don't want to lose what I've already got.
I know this is a basic question, but I've looked all over, and I haven't yet found a straightforward answer. I was hoping y'all would know. Thanks.
I think I've found an answer here: AWS EC2 new instance from image AMI
When launching an instance from an Amazon Machine Image (AMI), the disks will contain an exact copy of the disk at the time that the AMI was created.
In other words, if I start a new instance, I'll lose my installed software. WRONG!
Launching != starting. More editing to come once I get this completely figured out.
So, given that updated Windows images are created and deprecated all the time, and the Windows OS is constantly updated by Microsoft, one must wonder how it is a static Windows image can be used with other software? It seems like far more trouble than it's worth, if you've got to constantly reinstall your software to keep your Windows system up to date.
Amazon recently came up with a solution for that, here: Patching Windows
I don't know how to do it yet, but this seems like exactly what I need in order to keep Windows up to date, and keep my installed software intact.
all. First of all I am sorry if this question is better for SuperUser, I couldn't tell. If it is it would be great if someone could migrate it.
So anyway, I'm building this service for SharePoint in Visual Studio 2008 with C#. Of course I need to be able to debug it to build it fast. Unfortunately my OS is XP Pro which can't run SharePoint because it is not a server OS. Instead of reinstalling my OS (which would create other problems) I got Server 2003 + SharePoint Server 2007 up and running inside a virtual machine with Virtual PC. Is there some sort of pipe I can create from Visual Studio that will let me test my service from within the virtual machine?
Thank you!
I guess I should add, these are the tools I have been given. At this time, reinstalling or getting new equipment/software is not an option.
This is definitely stackoverflow worthy. It is a development process related question after all.
So you have two issues, deployment and debugging.
For deployment, there are really two ways to approach this. One is that you create a real .wsp package that you can deploy/install/upgrade via the SharePoint provided mechanisms. You really should have this prepared since it is the way that your final code should be deployed. The trouble is that you can only perform the deploy/install/upgrade via a machine connected to the farm. In this case it would be your VM. In cases where I have had to work this way, I have scripted the creation of the .wsp and copied it to the server. On the server is another script to do the deployment. Yes it is more steps than I would like but it does work and it is pretty mindless so it isn't too much of a hassle.
The second approach would be the quicker, less correct way. In this case if all you are doing is changing the code, then you just need to get your new DLL to replace the old one and bounce IIS. You might be able to do that all remotely via script fired from Visual Studio after build succeeds action.
As for debugging, you can certainly debug things remotely. Look into tutorials on remotely debugging processes using Visual Studio.