Bridge to Kubernetes for Visual Studio 2022

[mazhou-msft]

Is your feature request related to a problem? Please describe.
Today the Bridge to Kubernetes extension cannot be installed on Visual Studio 2022.

Describe the solution you'd like
Add support of Visual Studio 2022.

Describe alternatives you've considered
There are some breaking changes in the VS SDK for 2022, there is no walkaround unless the source can be recompiled to target VS 2022.

Additional context
Although VS 2022 is in early preview, I would like to use it primarily in personal projects.

[lolodi]

Hi @mazhou-msft,
thanks for reporting this issue. We have a work item tracking this and we'll report back once we shipped the fix.

[D3MaxT]

Hello,
VS2022 is out as an officially supported RC.

Is there an ETA for Bridge to Kubernetes extension for VS2022?
@lolodi

Thank you.

[lolodi]

Hi @D3MaxT ,
unfortunately no ETA yet. This item has not been prioritized yet, but we'll report back once it ships.
Thanks for your patience.

[Eneuman]

Any update on this?
VS 2022 gets releases in 7 hours from now, please don't leave us stranded on 2019 ;)

[Nico-VanHaaster]

Just updated to vs2022 and disappointed there is no B2K extension. Please provide an ETA on release.

[simyco]

hello, any ETA for this? thanks

[daniv-msft]

Sorry for the late update. We're figuring out the engineering resources to unblock this quickly. I expect I'll have more update to share by tomorrow (Friday) afternoon.

[mazhou-msft]

@daniv-msft let me know if I can be of any help.

[daniv-msft]

I just wanted to update you as mentioned above. It's more challenging than I expected to find the resources to make that change. We'll have more updates next week about this.

+@pragyamehta as I'll be out of office for the coming weeks.

[Eneuman]

Any update on this issue?

[irperez]

This means we cannot upgrade our pods to .NET 6 until this plugin goes out. And our .NET 5 code will be out of support soon. PLEASE MAKE THIS A PRIORITY!!!!

[angelobreuer]

While still suffering from this issue, there may be a workaround for this:

You can use the extension in Visual Studio Code by using an empty launch.json, and empty folder (except the launch.json) and choosing that you want to launch the application on your own. Then you can start the application using Visual Studio with using the benefits of Bridge to Kubernetes.

[irperez]

@angelobreuer I wouldn't call that exactly a work around. Our team uses Visual Studio, not Visual Studio code.

[Nico-VanHaaster]

Can we please get an update on the release date for the extension. This is now blocking us from Upgrading to dotnet core 6 and Visual Studio 2022.

[pragyamehta]

Hi all, thanks for your continued patience. We are currently designing a comprehensive experience for microservice development. As part this, we are determining how Bridge to Kubernetes fits into the new experience. Until this is decided, we are holding off releasing a Bridge to Kubernetes extension for Visual Studio 2022.

[irperez]

Please do not take away support for developing inside AKS.

Developing locally is not the same. In other words, Tye cannot replicate many of the tooling, integrations, mechanisms and workings that exist in K8s. It's in that integration that we can find issues that are not possible locally. And it would cause us to develop for local + the integrated environment. And that starts to introduce environment issues that we don't have today.

[irperez]

If so, can you please open source B2K so we can add support for VS 2022?

[Eneuman]

We have +40 micro services in our application and B2K is the best (if not the only) technology for us.

We can't use Tye since no laptop can handle running all the services at the same time.

We don't need a over simplified solution for running and deploying micro services because when you design event based systems with eventual consistency, learning some yaml specs is not the problem.

With todays B2K, we can have a developer working on their local machine in Sweden and a designer in following along on there computer in Spain and bugs found in test environment are so easily fixed by just debugging one service and ask the tester to repeat what he/she did.

B2K serves use really well. Yes you do need to know about k8 and kubctl etc, but that's not a bad thing.

We really hope that what ever you are considering, it's also include enterprise application dev cycle, and any transparency regarding your discussion are greatly appreciated.

[irperez]

We can't use Tye since no laptop can handle running all the services at the same time.

@Eneuman we're in the same situation. Tye is just not feasible for larger systems. B2K works really well.

[Nico-VanHaaster]

@mazhou-msft @pragyamehta This is not an acceptable answer. We were contacted by Microsoft to switch to Local Process for Kubernetes (now known as Bridge to Kubernetes). We undertook considerable dev \ R&D efforts to make the switch and shifting all our development teams processes.

This was done just over a year ago and we will not accept that you are not progressing further. If you are not going to support this on going you will need to make this open source so the rest of the community can carry it on.

You can contact me directly to discuss further.

[lolodi]

Hello,
while a decision is being made about the VS2022 extension, I believe a good workaround would be to use the CLI directly (instead of through the extension).

For Windows machines, the CLI can be downloaded here. The zip should be extracted to a location (e.g. %USERPROFILE%/.bridge-cli) and then that location should be added to the system’s PATH, and executed from the command line. Run bridge --help to see available commands.

To debug a service:

1. Make sure your kubeconfig context is pointing to the correct cluster and namespace. You can test it out by running kubectl config get-contexts and by checking the services with kubectl get services.
   To change namespace you can run kubectl config set-context --current --namespace=<namespacename>
2. In a terminal run bridge connect --service <your service name> --local-port <your local service port>
   This command will establish the connection, making the remote services available locally and making your local port available inside the cluster.
   
   Once the connection completes a new terminal window will open with the environment set as the remote container.
   
3. Inside the environment window start Visual Studio 2022 (or any other IDE you might want to use) and pass the path of your solution/project.

Now your machine is connected, and Visual Studio is running with the environment of the remote container. You can now run and debug your code as you would normally do without Bridge. Your code will be able to consume the dependencies in the cluster and will receive calls made to its pod in the cluster.

To run in isolated mode run kubectl config set-context --current --namespace=<namespacename> --routing <your-isolation-prefix>.
To route incoming calls, to your cluster, to the isolated instance, you can prepend "your-isolation-prefix" to the frontend hostname or use nip.io. e.g.:
my-isolation-prefix.contoso.com/frontend or
mt-isolation-prefix.20.69.123.123.nip.io/frontend (in case of IP address)

I hope this helps. Let me know if you encounter any problem with this.

[steverash]

Just to add - Bridge to Kubernetes is a key feature for our company too. We are rolling this out to around 10 teams over the next few months. We've just put considerable effort into building our local deployment/development approach around this.

The CLI workaround works - but I would like to see some commitment to this feature.

[irperez]

Seems like MSFT is not going to budge on this unless this issue gets more attention. Please spread the word and get people to thumbs up the original issue.

[ajaffie]

@lolodi The CLI workaround does not work if there are multi-line variables set in the config file (which work fine when using vscode and VS). Is there a solution for this?

[lolodi]

Hi @ajaffie,
this is unexpected, the parsing of the config file (KubernetesLocalProcessConfig.yaml) is done from within the CLI and both VS and VSCode are not altering that. Could you share a sample of your config file?

[ajaffie]

@lolodi Sure, here is most of the variable:

- name: JWT_PUB_KEY
  value: |
    -----BEGIN PUBLIC KEY-----
    MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs0OuHfQN16Hu5lR+P/7H
    snip
    xwIDAQAB
    -----END PUBLIC KEY-----

Here is some of the output in the console window:

C:\folder>SET "JWT_PUB_KEY=-----BEGIN PUBLIC KEY-----

C:\folder>MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs0OuHfQN16Hu5lR+P/7H
'MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs0OuHfQN16Hu5lR+P' is not recognized as an internal or external command,
operable program or batch file.

[lolodi]

@ajaffie I added quotes and it seems to work.

without the '|' character at the beginning it works also without quotes:

[ajaffie]

@lolodi That changes the way newlines are interpreted and the PemReader fails to parse the key.

[lolodi]

@ajaffie, I see. It seems to be a problem with how we are setting the env variables in the new CMD session. Bridge parses the file correctly, VS and VSCode set the environment without using CMD, the CLI starts a new CMD process and runs a script to set the environment, the script currently doesn't work for multiline values.
Feel free to open a separate issue to track this. I'll also add a task on our side.

In the mean time, as a workaround, you can start powershell from the CMD window instantiated by Bridge, and override the multiline env variable:

I know it's not ideal, but I hope it gets you unblocked.

[gevial]

Hi @lolodi - thanks for sharing the link to CLI. Can you also share the link to MacOS binary if it's available?
Since I can't find any official information on CLI release, maybe you can give a hing when this can be expected (roughly)?
Thanks

[Eneuman]

Any update on when/if there will be a extension for VS2022 ?

[BigMorty]

No update at this time.

[Eneuman]

Can you give us a timeframe for when we can have some info regarding this?
Or at least some information about what's beeing discussed.

[pragyamehta]

@Eneuman We really appreciate you following up. I want to assure everyone commenting on this thread that your voices are not going unheard. We will be updating this thread as soon as we are able to.
Wishing you all a Happy new year!

[irperez]

@Eneuman I feel your pain. We cannot upgrade to .NET 6 and VStudio 2022 until this happens. And its putting immense pressure on our team because of the fact that .NET 5 is not LTS. And so we're stuck between a rock and a hard place.

Our team does not use VS Code for development. So its difficult to ask our many teams to just change like that. We have tooling and plugins in place. Its not so simple to just simply flip things over. Also remember that Visual Studio has a built-in profiler. By us moving to VS Code, we lose that ability. So in essence, the $6000 license we paid for each developer would be trash by moving to code. And that isn't acceptable to our company and our team. So in my view, MSFT has dropped support for K8s in VStudio.

I can tell you from my point of view I'm not taking this lightly. Its a shame and makes our technology decisions look poor when this happens. I was told many times by MSFT evangelists that K8s was "THE WINNER" and that AKS was the future platform for hosting for docker. So we went that route especially given the debugging solution available worked very well.

What I would have expected was a roadmap on K8s development specifically. Well ahead any of this was released. At the very least we could have worked around any issues or slowly migrated to a new technology platform. But to find out that its not supported after its released. And we have no news or updates...

Thats not how to win trust with the community.

As of right now, until we can get some definitive roadmap, I cannot count with support for K8s and I will have to steer our software away from this solution altogether.

[plaisted]

I know it's not the fault of anyone here but the lack of transparency is frustrating. Our enterprise VS subscriptions actually require a third party license to support something as fundamental as containers (Docker Desktop). Now Kubernetes remote development support has effectively been dropped (or requires staying on .net versions soon to be EOL). It appears (based on comments in this thread and near-dead open source MS k8 projects) Microsoft is rethinking their K8 / container development approach but while they finish that we're stuck in limbo. As it stands our expensive IDE is actually worse than VS Code for many modern use cases. We also don't know when/if/how improvements will occur making any planning impossible.

[BigMorty]

Great news! We have listened your feedback and plan to build and release a Bridge to Kubernetes extension for Visual Studio 2022. We plan to start on this soon and will release it on the Marketplace as soon as we can.

[BigMorty]

Y'all asked for transparency... I want to mention that while we plan to release a VS 2022 extension, we also plan to put out a survey to find out more information about how Bridge users use the product. How often do they use and in what situations? We also plan to talk to some of the current uses on a Teams call to get an even deeper understanding of their usage. Our plan is to share a recap of the survey and talks on this forum.

[gevial]

Thanks @BigMorty ! I'm not using Bridge but hopefully my feedback could be useful. We're running a consultancy engagement for an enterprise aiming to redesign one of their applications to microservices/cloud. As a part of that we did technology analysis for various focus areas and for local development we picked Telepresence over Bridge. One of the main reasons was the absence of CLI.
Looking forward to the next versions of Bridge, keep the ball rolling guys, this is a very promising product!

[BigMorty]

@gevial, did you see the above post discussing the CLI we have for Bridge? #203 (comment)

[gevial]

Yes, thanks, I've seen that, but as far as I understand, there's no currently stable release for CLI and it's not available on Mac.

[BigMorty]

Fair enough @gevial, you are right.

[RobbieReboot]

where is the info on the vs2022 bridge so we have some idea of timeline to release?

[BigMorty]

The VS 2022 extension is code complete, and we are now testing it. It should be in the Marketplace in a matter of weeks!

[Eneuman]

Nice :)
Does this update also include the fix for tokens not renewing?

(It was fixed in VS Code extension quite some time ago)

[RobbieReboot]

Awesome @BigMorty, thanks for the update :)

[irperez]

Thank you guys!!! I appreciate the effort!

Would it be a stretch to make the extension open source so we can help if needed?
A separate effort, but more of a question in general. I know you guys want to move on and do other projects. Open sourcing this would go a long way to alleviate some of that pressure.

[BigMorty]

@Eneuman - The VS 2022 extension is the same codebase as the VS 2019 extension, just with the minimal changes to make it install and work in VS 2022.

@irperez - Not sure, but great question!

[glebkozh]

Hi @lolodi!
Could you please tell how can I restore original version of service in cluster after I'm done with debuging in local environment using CLI? Thanks!

[lolodi]

@glebkozh
When connecting with the cli, a new terminal window gets created, where all the environment variables are set, and from where you run your code/IDE.
Once you are done debugging closing that window will trigger the restore.
Let me know if you encounter any problem with this.

[glebkozh]

@lolodi yes, thanks a lot, works perfectly!

[Eneuman]

Any news?

[daniv-msft]

@Eneuman Yes, we're planning to have it out before the end of this month (so ~10 days). We've ran through some platform/infrastructure issues that slowed us down. Sorry for the wait!

[zivfuture]

Any update?

[daniv-msft]

I'm happy to announce that the new extension for VS 2022 was released this morning! Kudos to the team members who made it happen: https://marketplace.visualstudio.com/items?itemName=ms-azuretools.mindaro2022

Thanks everyone for your patience!