I create a new Teams application in Visual Studio 2022 (17.4.4). When I try the "Prepare Teams App Dependencies", I get a failure from AppStudioPlugin with the message "API call to Developer Portal failed: Error, connect EACCES 52.113.194.132:443, API name: create-app, ..."
I am behind a proxy, and I see a drop in the firewall logs to 52.113.194.132:443, so it's not going to the proxy.
When I open a browser on that machine, I can go to the developer portal (https://dev.teams.microsoft.com/) without a problem, so the proxy does allow this.
When I open port 443 in the firewall, everything works.
My question is: How do I get it to work via the proxy ?
I did already try to add the proxy to the visual studio config, but also that did not make a difference.
17.4 VS Teams Toolkit uses a language server to handle data between VS and Teams Dev portal. You can try to add this language server to your proxy and test it.
Language server location: ~\appdata\local\microsoft\visualstudio\{VS_version}\extensions\Microsoft\teams toolkit\{Teams_toolkit_version}\server.exe
Related
I have hosted a simple BOT Chat on my IIS server, with URL being http://localhost:3978. But when i access http://localhost/3978/api/messages. It throws error "HTTP Error 404.0 - Not Found". so when i am giving these as my end point in emulator , it s unable to connect and same message is displayed. Please anyone can help me on this
You can't conect because you need conect to http://localhost:3978/api/messages not http://localhost/3978/api/messages, if is failed and you are deploy in a IIS server, conect to http://localhost/api/messages
If you're hosting in IIS you want to enter either
http://localhost/api/messages OR http://localhost/YourIISAppName/api/messages in the bot emulator. You can only use http://localhost:3879/api/messages if your code is running in visual studio and is set to run on PORT 3879 (which you can change in the properties of your bot application in VS). Also, make sure IIS is configured to accept POST requests.
I have configured TFS Proxy server and have set the source control setting of my local VS client. Also TFS Application server & TFS Proxy server both are in same network Domain.
But when i am taking get latest of any team project and second time taking the get latest of same team project at different machine but files are downloading Main server and giving below warning.
TF15013: The requested Team Foundation Server is not registered with the proxy server.
Can Anyone help me out how to resolve this issue & make fast get latest.
Thanks,
You can try to use the proxy command to configure your client to use a proxy server: see Proxy Command
eg :
c:\projects>tf proxy /add http://server:8081 /default:global /collection:http://tfsserver:8080/
If that still not work, recommend you to reconfigure the Proxy, you must use service accounts to install Team Foundation Server, and Team Foundation Server Proxy. These service accounts become the identity for the installed component.
By default, every component uses a built-in account (such as Network Service) as its service account.Built-in accounts do not use passwords and already have the Log on as a service permission, making them easier to manage, especially in a domain environment. See requirements.
After that you can reference below link to configure the TFS proxy to work with Your TFS:
https://blogs.msdn.microsoft.com/buckh/2016/10/12/how-to-configure-a-tfs-proxy-to-work-with-team-services/
Update:
TFS 2013 is Xaml build system, double chick the definition will pop up the definition to edit. TFS 2017 is vNext build system, it will redirect to web client build progress page. That's by design, not related to the source settings.
And as far as I know, there isn't the utility or third part tools can open the vNext build definition in VS directly, vNext build definition is task independent, you can edit it conveniently via web portal.
I have a question as to how the Visual Studio 2013 debug emulator for Web API works.
I had built a Web API project in Visual Studio 2013 to access a database on an external server. The code was built using VS2013's ASP.NET Web Application project template for a Web API application. Once built, running debug opened a browser window for localhost port 56618, which allowed access from Fiddler to test Http requests.
Once I had the project finished, I published it to a website using Web Deploy to IIS. However, whilst the page would open (now at localhost:9812), an http request would throw an Internal Server Error 500.
Perusing the IIS FailedReqLogFiles, I noticed that the reason that it was failing was that the database server was refusing access to '<Domain>\<machine-name>$'.
I added '<Domain>\<machine-name>$' as a valid login (windows authentication, as the connection string included "Integrated Security=true") on the sql instance with read and write privileges, and the problem was resolved.
The question is, why didn't the Visual Studio debug emulator have the same issue?
Because the emulator was running the website under the context of your own account (e.g. <Domain>\You). Your account had access to the database, so there was no issue.
When you published it to IIS, it started running under the context of a different account (<Domain>\Machine-Name - but there are other variants depending on how IIS is configured, and the version of IIS), which didn't have access to your database.
With VS 2010 Web Deploy is functional and working without issue. At the same time, Web Deploy from VS 2012 fails, indicating that the server did not respond and suggesting this link.
This notes the following conditions, all of which are fulfilled.
You can ping the remote machine
That the msdepsvc or wmsvc service is started on the remote server.
Your firewall is not blocking incoming connections of your ports on the destination. If you used the default installation, then it would be 80 for msdepsvc and 8172 for wmsvc
Web Deploy is still functioning for VS2010.
How can this be solved?
Clearly an example of not reading all the documentation first. However, for those looking to understand some of the changes here's what I found.
VS 2012 uses the Web Deployment Agent Service and NOT the Web Management Service
Local deployment is to "http://Your Server/msdeployagentservice" and NOT :8172/msdeploy.axd
For a complete account of the many options GO HERE!
Hope this helps someone else.
I've installed Web Deploy 2.1 on a Server 2008 R2 running under VMWare.
In the IIS Manager (Management Service applet) I can see that "Enable Remote Connections" is checked and the port is set to 8172. Under "IIS Manager Permissions" I've added my Windows account (CORP\ekkis) and under the "Authentication" applet (for IIS) I have enabled "Windows Authentication".
I've also turned off the firewall.
So from the command line I test the system to work like this:
C:\Program Files\IIS\Microsoft Web Deploy V2>msdeploy -verb:dump -source:contentPath=\temp,wmsvc=192.168.0.70,username=CORP\ekkis,password=MyPass,authType=Basic -allowUntrusted=True
and get this:
Info: Using ID '9b954a0f-ff07-4e77-ba2c-d27472f5fda0' for connections to the rem
ote server.
Error Code: ERROR_USER_UNAUTHORIZED
More Information: Connected to the destination computer ("192.168.0.70") using t
he Web Management Service, but could not authorize. Make sure that you are using
the correct user name and password, that the site you are connecting to exists,
and that the credentials represent a user who has permissions to access the sit
e.
Error: Object of type 'contentPath' and path '\temp' cannot be created.
Error: The remote server returned an error: (401) Unauthorized.
Error count: 1.
I've also tried deploying with Visual Studio 2010 from the host OS with the following service urls (I haven't found proper documentation on how to form this url):
https://192.168.0.70/
https://192.168.0.70:8172/
https://192.168.0.70:8172/MsDeployAgentService/
https://192.168.0.70/MsDeployAgentService/
I've tried the non-secure versions as well but just cannot get it to work. What is the correct format for the url? and what permissions am I missing?
the errors from VS have varied depending on how I attempt it but below is a sample:
Could not complete the request to remote agent URL 'http://192.168.0.70:8172//MSDEPLOYAGENTSERVICE'.
The underlying connection was closed: An unexpected error occurred on a receive.
Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
An existing connection was forcibly closed by the remote host
Publish failed to deploy.
there really should be a guide out there to do this (yes, I've googled myself blue in the face)!
thanks - ekkis
ok, I've figured out that the correct url is:
https://192.168.0.70:8172/MsDeploy.axd
and that having the "Windows Authentication" enabled doesn't seem to make a difference. Also, having my account in the "Managers" list doesn't seem to make a difference either.
so the back end was all working fine (I've turned off the Web Deployment Agent Service). it was just the url I had wrong.