After installing VS2019 16.5.1 and 16.5.2 I receive a message that Windows Defender has locked some features of Xamarin.Messaging.Broker and asking if I should allow it.
Normally I would as it seems to be part of Visual Studio but this executable is located in my appdata\local\temp file, which I would not expect it to be. Searching the net for info about this yields little in the way of good information.
Does anyoe know what it does and why on earth would you put an exe in the local user temp?
My message appear exactly after upgrade 16.5.0 to 16.5.3, We all see this message in 16.5.2 version and above.
So as far as we know this happened because microsoft add something new in 16.5.2 and above, It can't be anything except microsoft work since we all have seen this firewall message.
My file was in C:\users\username\appdata\local\temp\xamarin\xma\broker.local\16.5.000.533\broker.exe
This access will add a record in firewall advanced "Inbound Rules" Which means grant an access from outside to our PCs on UDP/TCP.
Conclusion :
Personaly i allowd this file in firewall because i have tons of problems in xamarin (special to connect to Mac) and i don't want to add more, I suggest you all do the same.
I don't know why it would be in that location, but this article lists the endpoints to allow for a xamarin firewall configuration. Perhaps it might assist in some way.
https://learn.microsoft.com/en-us/xamarin/get-started/installation/firewall
In VS2022 I just had this security alert just as I went to open the toolbox to add a Button to a new WPF project.
**Windows Defender Firewall has blocked some features of this app**
Name: Broker
Publisher: Xamarin
Path: C:\users\username\appdata\local\temp\xamarin\xma\local\broker\17.3.0.288\broker.exe
Allow Broker to communicate on these networks:
✔ Private networks, such as my home or work network
I refused it.
Related
First off, I read all other Questions, that relate to this, I did an extensive google search on this topic and could not get a working answer.
I installed the Community Version of Visual Studio 2015 in mid November and been using it since then. After finishing my project, I went back to pen and paper for new formulas and noe came back to implement all those neat things.
Now it says, that my trial license has expired and should be renewed. I already read, I should use my MicrosoftAccount to do that, and proceeded by doing that.
Now this happened
It says, I should check firewall and prxoy settings and I read about contactiong the administrator. So that, what I did, but he says, there is no proxy, no block by firewall or anything else.
When running VS as administrator (after entering my credentials) I can create new projects and debug existing ones, so no problem there. However I can not use the program as normal user.
I read somewhere here to try repair it via systemcontrol, but that did not work either.
Does anyone has a solution?
In addition: There is also no "Enter License Key here" field, so that is also not an option.
(several Days later)
Halleluja, I found the answer! After digging through some Microsoft Help-Forums, I came upon this Thread, that not only perfectly describes my problem, but also gives a solution. So dear visitor from the future, who googled the problem and came upen this Stackoverflow Question: Follow the link above!
So, after sniffing packets harder than a drug addict, trying to find a difference in TLS exchanges between my computer and VS licensing server when using a domain account and when a using local account, and noticing no difference, I recalled why I had pushed this hypothesis to the side: our network supports TLS 1.2 perfectly well, as I can connect to TLS 1.2-only remote hosts without any issue.
This means the issue lies elsewhere, and is caused by Visual Studio treating domain accounts and local accounts differently when trying to renew licensing information.
The good news is I've found why and how to fix it.
I recalled that earlier this year, when we upgraded our commercial department from Windows 7 to Windows 10, they all encountered issues while trying to configure their mail accounts on Microsoft Outlook: an unknown error 0x8004011c. If you search around for it you'll quickly find that this only happens when using domain accounts and not when using local accounts (sounds familiar, heh?). The fix to bypass this issue is to set a specific Windows cryptography-related registry key.
When digging a little deeper, you can find that this fix is related to KB 3000850 (which I sadly cannot link to due to my account not being verified) and is actually described in the "Known issues" section, as well as in Samba-related documentation ("Required Settings for Samba NT4 Domains").
In short: Windows 8.1+ clients (with KB3000850) joined to an NT-Style domain are not able to use Windows Credential Manager. This doesn't occur when not using a NT-Style domain. The fix seems to globally authorize using Windows Credential Manager whatever the domain context.
So, to wrap it up, if:
You have a NT-Style domain (such as when using a Samba domain controller)
You have Windows 8.1 or later
vYou encounter issues when renewing your Visual Studio license
Then, set the following registry key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb]
"ProtectionPolicy"=dword:00000001
This solved the issue on our domain, for all machines and accounts tested.
As to why Visual Studio 2015 needs to use Windows Credential Manager and not Visual Studio 2013, someone from Microsoft will have to chime in there to explain because I have no clue.
You are using a very old Samba server that uses unsupported features. NT4 came out in 1995. Active Directory didn't exist back then. A lot has changed in the last 20 years, including strengthening security and gradually removing older, less secure features like LanMan and NT4 domains.
Instead of weakening security, you should follow the advice posted in the page you linked, Required Settings for Samba NT4 Domains:
Microsoft discontinued the official support for NT4 domains in their Windows operating systems. ... Anyway, consider migrating to a Samba Active Directory (AD) to avoid problems if a future update from Microsoft disables or removes the unsupported NT4 features.
Recently i installed Microsoft Visual Studio 2013 Preview Ultimate on Windows 7. Everything went smoothly except now i can't access www.microsoft.com and www.skype.com anymore. Tried latest IE10 and FireFox, both show blank page when accessing the above mentioned web sites. Firefox in its left bottom corner shows that it is waiting for ajax.aspnetcdn.com.
I'd really like not to reinstall OS on my machine, so i'd appreciate any idea how to fix this. For myself i tried to stop Firewall service and disable MS Security Essentials runtime protection, neither helped.
PS: I can access www.microsoft.com and www.skype.com from another machine in the same local network
UPDATE: i am using tfs.visulstudio.com as my TFS server and it opens fine if i am not signed in. But once i am trying to log in it opens blank, like browser is waiting for something (the same as for microsoft.com and skype.com). Something related to live ID?
Don't think this is the website to post this kind of question but try uninstalling VS2013 preview because you think that's causing the problem. Search in Google for people getting similar problem. I also don't think it is VS2013 because I can't think of anyway of how VS2013 would somehow disable you from going to a certain website. Make sure the sites weren't down at the time or if you're having something kind of Internet server issues.
skype is owned by microsoft, so you can't enter both microsoft pages. This could be related with some kind of ISP (Internet Service Provider) and not with VS2013, or you can try rebooting your router. Last thing i would do is traceroute both address and see where they fall.
I wanted to write this as a comment but I don't have enough reputation yet. Anyway, obviously trying to uninstall the program and trying again would be a good start as already mentioned, but you should also look inside your hosts file for any weird redirections some virus of malware might have set up. It's located at "C:\Windows\System32\drivers\etc" and you can open this inside notepad (might require notepad to be run as an administrator). Check to see if skype.com or microsoft.com are in there and are pointing to a different IP address. If they are you can just remove them and save the file (might require a restart to take effect). If still no luck you should try a livecd of a linux distro to make sure the problem is definitely inside your windows somewhere.
Let us know how it goes.
Recently our Development user group (Windows) has started showing with a Red Cross in Team Explorer and we cannot expand it anymore.
I have tried removing and re-adding the group but to no avail.
Does anyone know why it would display like this?
We are using TFS 2010 with VS2010 SP1 and August's Power Toys.!
BTW, "Technical Testing Team" is another Windows Domain User Group, just like Development and that works OK.
In general, the red crosses on particular services are caused either by that service being unavailable or by permissions issues...
Are you still able to perform actions that require admin permissions? Does this apply to a single project or all?
How are you defining your developers? A windows domain group? If so, is the TFS server able to see the DC?
I'd suggest you try installing Team Explorer on the TFS server and running it when logged on as yourself - see if you have the same problem. If not, it may be network or firewall problems between your dev machine and the server. At least it would narrow the problem down.
Edit 1:
Do reports work properly? (Specifically, do the graphs show up in reports)?
What auth are you using? Kerberos?
What account is TFS running as? What permissions (if any) does that account have on the network?
Can you see the security information you'd expect in the TFS_Configuration database? (Try tbl_SecurityAccessControlEntry) [Usual "Change nothing, do it at your own risk" disclaimer]
Edit 2:
As per the install docs, the TFS service should be running under its own account (IIRC they suggest Domain\TFS.Service). Check the permissions on the windows services on the TFS Server and see who they're running as. Makes sure the permissions for that user are correct as per the installation instructions
NTLM can cause problems as it doesn't allow credentials to be delegated/relayed the way Kerberos does (and has some picky setup requirements) - but that's obviously not why it's broken all of a sudden (and that usually manifests as graphs not displaying in reports).
WRT: the SecurityAccessControlEntry table, I was more interested in making sure there were entries and that it could be read properly than the contents.
I assume you've tried deleting/recreating groups - If not, give it a shot (deleting the domain group may be an issue with other services but try using a different (new) group and removing the old one from TFS entirely)
I have to admit I'm running out of ideas after that. If it were me, I'd try a clean install on a new server/VM and either point the new install at the old data store [multiple server setup] or export/import projects [single server setup].
For Multiple server setups, this would determine if it's a TFS installation issue/data corruption. For single-server, there's a good chance this would just clean up the problem. You could, of course, also ex/import on multi-server too if it does turn out to be a data thing.
You may want to hang on to see if someone has a less drastic solution.
Looking in the General tab of the VS Output windows there is a message:
Skipping loading group Development into Team Members because it has 102 members.
Looks like VS has a limit on here.
We are working with Visual Studio 2010 and Team Foundation Server 2010. We did not have any problems for about half a year, but:
Since a couple of days we get the following error: Team Foundation services are not available from server (...) The remote name could not be resolved; (...)
The problem occurs randomly (we are unable - yet - to pinpoint the conditions on which it occurs) and persists until we restart Visual Studio. The problem occurs about 8 times per day per developer.
Because we seem not to get past this problem and we cannot find anybody writing about this specific combination (the error and the 'remote name' part), I thought it wise to ask you guys about it ;) . Could anyone please help?
This is a client, server or infrastructure related problem on network level. The DNS entry for your TFS server cannot be resolved correctly at times for host dfz-vm223.
Suggestions for troubleshooting:
On some developer systems, replace the hostname dfz-vm223 by the ip-address of the TFS server. If the problem stop occuring there the DNS system is instable.
Setup a continuous ping stream (ping -t dfz-vmm223 from command window) and see if the host system is pingable in case you have TFS server problems.
Just found out what the problem was: the problem is proxy related. When we disable our proxy, the problem is gone. It appears our proxy and TFS are troublesome together. If anyone experiences the same problem and you are working with a proxy server, I would suggest you try disabling the proxy too.
I had the same problem, although I'm using VS2012 and a WAN connection to TFS.
I solved the problem by flushing the DNS cache.
To flush the DNS cache, start a command prompt with admin rights: ipconfig /flushdns
You need to do this in all the computers where the problem occurs.
I know this is old, but I had this problem sometimes when I ran Fiddler.
Sometimes Fiddler would crash or not clean up properly and the whole machine would get into some weird state where not even reboots were helping. The solution to it usually is to start Fiddler again, turn off any interceptors/collecting traffic and shut it down again.
Some of my co-workers and I had this problem as well. Out of about 25 developers, most never got this error. But three of us got it pretty consistently. The symptoms are identical, but we are using Visual Studio 2013 almost exclusively. In this version of Visual Studio, the error is preceded by the code: TF400324.
We found eventually that the three of us had all installed Productivity Power Tools 2013. And the developers that were not affected by this error had not installed it. Most had not heard of it. This used to be a very popular extension, so I have always installed it as I set up my system since about 2007. But apparently, in its modern incarnation in Visual Studio 2013, perhaps in combination with some quirk in our network or something, it can cause this problem. We have each uninstalled it, and have not gotten this error since. (It's been several months now.)
If you have this extension installed, you probably already know about it, because you probably installed it yourself. You probably started using it years ago, and it became a habit to add to each new installation. You will find that today, the default installation of Visual Studio actually includes most of its features already. To uninstall, go to Tools --> Extensions and Updates... Then click on Productivity Power Tools 2013, and click Uninstall.
Hade the same issue. For whatever reason the windows DNS Client service on my PC wasn't running. Changing it from Disabled to Automatic solved this problem for me.
Too long for comments:
First off, as #kroonwijk stated, this is an infrastructure issue. Your DNS queries are either timing out or the DNS server is not responding at certain times.
In a comment you mentioned a change over from regular machines to laptops for your entire dev team. If I had to make a bet I'd say that the DNS configuration on the laptops is not the same as what you had on the other machines.
You need to take this up with your infrastructure people. If you still have access to the older machines boot one of them up and compare the IP configuration. If not, get them to fix the problem. The DNS resolution problem could be any one of a number of factors. For example, the new machines could be pointing to an incorrect DNS server that has network issues or their might be some incompatibility between how Win7 makes DNS requests and your DNS server.
I have also experienced this problem and it doesn't always have to do with name resolution.
If you add an entry to your %systemroot%/system32/drivers/etc/hosts file for your TFS server, it removes any dependance on your name resolution servers.
If you are still experiencing the problem, then it has to do with either visual studio or one of the VS Extensions that you are running. There may be a memory leak somewhere. Disable all your Extensions using the extension manager, restart VS, and see if you still experience the problem.
I have a WiX installer project where I have added two firewall exceptions as part of the installer by using the WiX FirewallException. This works great when the client machine is using Windows Firewall, but I got a report that a user failed to get the solution running when using Norman's Personal Firewall. Some question regarding this:
Will other firewall products in general respect rules added to the Windows Firewall? If so - is this just an import or will firewall products always respect changes to Windows Firewall rules?
Are there any generic way to add firewall exceptions so that all/many of the firewalls will respect them during an installer such as the Firewall extensions in WiX?
Will usage of netsh result in firewall exceptions getting added to other products than Windows Firewall?
I believe the answer to all of that is no, no and no. This is one of the reasons that I don't even try to do any of this in my installs. I always encourage application development to write systems that don't need massaging of the firewall and/or get the systems engineers to work with documentation to properly document to the end user the networking requirements. I only attempt automagical in the installer if everyone understands it's a best effort attempt and that documentation must be available to assist users in integrating into their custom environment. That and I'm naturally adverse to having my way with users operating system configuration settings without their (true) consent.