In my organization we have a sonarqube server set up and working - there we can see the results on a daily basis. Now we want to introduce sonarlint to see exactly the same state on the local developer PC-s and on the server. I've set up the sonarlint extensions and bind the connection sucessfully. When i change an issue in the server e.g.: to info, the modifications are not getting synchronized to the local PC-s, and i have no idea how to fetch the server state.
Does anybody solved this issue already?
(IDE: VS 2017 Enterprise)
Related
We have installed VisualSVN server 3.5 on windows server 2012 r2. When we browsing the repository in the VisualSVN Server Manager, WMI provide host process has started and it uses the very very less cpu usage(4%) even overall CPU usage is less(20%). This means WMI is very slow in background.
we have the script to set the VisualSVN permission using WMI, this WMI query also failed with unknown cause.
Please, describe the issue in detail. It is hard to tell what the root cause is from the current issue summary. Checking VisualSVN Server logs and Windows Application / System / WMI logs can help.
Note that you can always contact support#visualsvn.com for assistance.
we have the script to set the Visual SVN permission using WMI, this
WMI query also failed with unknown cause.
Try the *-SvnAccessRule PowerShell cmdlets such as Get-SvnAccessRule, Add-SvnAccessRule and Set-SvnAccessRule. The access rule management cmdlets help you automate permission management, perform permission modifications in batch and generate permission reports.
IMPORTANT: VisualSVN Server 3.5.x release family is out of support since February 28, 2018. 3.5.x release family does not receive patch updates. Please, plan to upgrade your VisualSVN Server instance to the latest version, VisualSVN Server 3.9. Read the article KB138: Upgrading to VisualSVN Server 3.9 before beginning the upgrade. For the complete list of changes between version 3.5 and 3.9, take a look at the changelog.
I am trying to remote debug an Asp.Net Core Web Application (with Web API) project deployed as an Azure App Service with Visual Studio 2017 Professional.
Followed the instructions as documented here. Essentially, using the Server Explorer-->App Service-->Attach Debugger
Also, enabled the necessary firewall ports as mentioned. The ones I opened are TCP (4022, 4023) and UDP (3702). Also, ensure remote debugger application is in allowed list of apps in Windows Firewall. Documentation for the firewall steps.
Despite all the settings, I am getting following error
System.Runtime.InteropServices.COMException (0x89710023): Unable to connect to the Microsoft Visual Studio Remote Debugger named 'essamplepoc2.azurewebsites.net'. The Visual Studio 2017 Remote Debugger (MSVSMON.EXE) does not appear to be running on the remote computer. This may be because a firewall is preventing communication to the remote computer. Please see Help for assistance on configuring remote debugging.
at Microsoft.VisualStudio.Debugger.Interop.Internal.IDebuggerInternal120.ConnectToServer(String szServerName, VsDebugRemoteConnectOptions[] pConnectOptions, CONNECT_REASON ConnectReason, Int32 fIncrementUsageCount, IDebugCoreServer3& ppServer)
at Microsoft.VisualStudio.Web.Azure.MicrosoftWeb.Operations.RemoteDiagnosticsSessionBase.ConnectToServer(String site, String user, String password)
Any suggestion would be helpful.
The issue is resolved. We had to open outbound ports 4024 for VS 2019, 4022 for VS 2017 and 4020 for VS 2015 on corporate firewall.
For more info check these out:
https://learn.microsoft.com/en-us/visualstudio/debugger/remote-debugger-port-assignments?view=vs-2019
https://learn.microsoft.com/en-us/visualstudio/debugger/configure-the-windows-firewall-for-remote-debugging?view=vs-2019
I also had this problem. I solved it by changing the Platform from 32-bit to 64-bit in Application Settings as I am trying to debug from 64-bit machine.
It seems remote debugging is not turned on for your App Service.
Open your App Service in the Azure portal and go to Application Settings. Then turn Remote Debugging to On and select Visual Studio Version to 2017.
It should look like this:
Screenshot source
I hope this helps.
First, what did NOT work. Opening the port in my Firewall did not work for me. Restarting my local machine did not work, neither did restarting the app in Azure, nor updating VS2019 with the installer. I kept getting:
System.Runtime.InteropServices.COMException (0x89710023): Unable to connect to the Microsoft Visual Studio Remote Debugger named 'empirepipedriveapi-newversion.azurewebsites.net'. The connection with the remote endpoint was terminated.
Finally, what DID work, I deleted the deployment slot and then added it again, I deleted the publish profile in Visual Studio 2019 and recreated it again, a published the app (without even recompiling it) and then WAS able to connect (I did refresh the available slots in the Cloud Explorer first just to be overly careful). I believe, and this is the 2nd time in about a year, that, on rare occasion, the deployment slot can become corrupted. I noticed this time when I published the app, it took longer and it seemed much more activity took place, leading me to believe that there was code in the old slot that was is not refreshed on each and every publish and it must have become corrupted.
I am a little new to active MQ so please bear with me.
I am trying to take advantage of the ActiveMQ priority backup feature for some of my Java and CPP applications. I have two brokers on two different servers (local and remote), and I want the following behavior for my apps.
Always connect to local broker on startup
If local broker goes down, connect to remote
While connected to remote, if local comes back up, we then reconnect to local.
I have had success with testing it on the java apps by simply adding priorityBackup to my uri options
i.e.
failover:(tcp://local:61616,tcp://remote:61616)?randomize=false&priorityBackup=true
However stuff isn't going as smoothly on the CPP side.
The following works fine on the CPP apps (with basic working failover functionality - aka jumping to remote when local goes down )
failover:(tcp://local:61616,tcp://remote:61616)?randomize=false
But updating the uri options with priorityBackup seems to break failover functionality completely (my apps never failover to the remote broker, they just stay in some kind of broker-less/limbo state when their local broker goes down)
failover:(tcp://local:61616,tcp://remote:61616)?randomize=false&priorityBackup=true
Is there anything I am missing here? Extra uri options that I should have included?
UPDATE: Transport connector info
<transportConnectors>
<transportConnector name="ClientOpenwire" uri="tcp://0.0.0.0:61616?wireFormat.maxInactivityDuration=7000"/>
<transportConnector name="Broker2BrokerOpenwire" uri="tcp://0.0.0.0:62627?wireFormat.maxInactivityDuration=5000"/>
<transportConnector name="stompConnector" uri="stomp://0.0.0.0:62623"/>
</transportConnectors>
backup and priorityBackup parameters are handled in completely different way in Java and C++ implementation of the library.
Java implementation works well but unfortunately C++ implementation is broken. There are no extra options that can fix this issue. Serious changes in library are required to resolve this issue.
I was testing this issue using activemq-cpp-library-3.8.3, and brokers in various versions (5.10.0, 5.11.1). Issue is not fixed in 3.8.4 release.
I am working with Informatica Developer - Power-Center. I have it installed on 2 computers: my local PC and the MS Server where the Informatica Server is also installed.
I defined a new connection and tested it by clicking Test Connection. On my PC the test works fine but when I test the connection on the server the test fails with the following error: "[REL_10611] Error returned during ODBC access. ErrorCode=[-1]. Reason=[[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified]."
Another strange thing is that the mapping that includes a relational data object that uses this connection works even on the server and adds row to the DB.
Does anybody know why this could be happening? Is this a bug in the Informatica Developer?
Did you create the ODBC data source on the server? The data source needs to be created on both your local PC and on the server. When using the Developer Tool (and the Power Center client tools for that matter), some operations are executed from your local workstation and some are executed on the Data Integration Service (DIS).
I've got some code that runs in Enterprise guide (SAS Enterprise build, Windows locally, Unix server), which imports a large table via a local install of PC File server. It runs fine for me, but is slow to the point of uselessness for the system tester.
When I use his SAS identity on my windows PC, the code works; but when I use my SAS identity on his machine it doesn't, so it appears to be a problem with the local machine. We have the same version of EG (same hot fixes installed) connecting to the same server (with the same roles) running the same code in the same project, connecting to the same Access database.
Even a suggestion of what to test next would be greatly appreciated!
libname ACCESS_DB pcfiles path="&db_path"
server=&_CLIENTMACHINE
port=9621;
data permanent.&output_table (keep=[lots of vars]);
format [lots of vars];
length [lots of vars];
set ACCESS_DB.&source_table (rename=([some awkward vars]));
if [var]=[value];
[build some new vars, nothing scary];
;
run;
Addenda The PC files server is running on the same machine where the EG project is being run in both case - we both have the same version installed. &db_path is the location of the Access database - on a network file store both users can access (in fact other, smaller tables can be retrieved by both users in a sensible amount of time). This server is administered by IT and not a server we as the business can get software installed on.
The resolution of your problem will require more details and best solved by dialog with SAS Tech Support. The "online ticket" form is here or you can call them by phone.
For example, is the PCFILES server running locally on both your machine and your tester's machine? If yes, is the file referenced by &db_path on a network file server and does your tester have similar access (meaning both of you can reach it the same way)? Have you considered installing the PCFILE server on your file server rather than on your local PC? Too many questions, I think, for a forum like this. But I could be wrong (its happened before); perhaps others will have a great answer.