I am using TFS2012 as source control with VS2012.
When I checkin any file which is checked-out , output window shows this error:
ProfileController.cs has been automatically checked out for editing.
The calling thread cannot access this object because a different thread owns it.
The calling thread cannot access this object because a different thread owns it.
Tried to resolve this(restarted VS2012) and also deleted the server Work-space and recreated again, but the problem is still same.
Any file I checkout in source-control from solution-explorer, does same behavior.
Any help?
I had the same problem, disconnecting and re-connecting to the TFS2012 Service solved it
I get this error with VS 2012 when I try to check in files. To get around it, I open VS, then immediately go under "Team" and select "Connect to Team Foundation Server..." BEFORE I open any solutions. Then any solutions I open and work on can be checked in without this error appearing.
Related
Can anyone help as I am unable to execute the azure functions and getting this error message everytime.
Indeed, this is an antivirus policy issue. One can confirm this by going to your antivirus logs. I was using Symantec.
Steps to view logs in Symantec -
Open Symantec>View Logs>Client Management>View Logs.
The logs will contain an entry with keyword "BLOCK" with the path of blocked exe (as in snapshot attached in question).
1/27/2020 4:04:05 PM User Event 10 Block [AC1-1.1] List all applications you want to block below, by clicking the Add button. - Target MD5=d028f52957a8759ccbe6845e79090898 - Target Arguments="host start --port 7071 --pause-on-error" Create Process 0 1/27/2020 4:03:04 PM 1/27/2020 4:03:04 PM Block applications from running | [AC1-1.1] Block these applications 10.202.100.23 16776 C:\Users\<username>\AppData\Local\AzureFunctionsTools\Releases\2.43.0\cli_x64\func.exe 200704 Bytes Alert
Once my security team updated the policy, the azure function ran perfectly!
Finally after two days of struggle I got the answer. The Azure core Tools emulator "func.exe" is located in AzureFunctionstools folder which is located in appdata.
Appdata folder is the place for all the applications to install their configrations and helping component like .dlls or so. And, thus Appdata is an important folder which is hidden by default.
In many case changing the visibility of appdata folder from hidden to visible resolves the problem.
I tried to execute a sample exe from inside and outside of appdata folder and the sample exe was not accessible when it was inside appdata. Same scenario happens with "func.exe", it was executing outside of appdata folder. It was a clear indication that something is restricting access. and only an antivirus would do that.
I make changes in the antivirus policy (added the path in Exception) and it started working.
Here are the screenshots for reference:
As a solution: you can perform the following:
Make the appdata visibility from hidden to visible. or,
Right click on the folder, PRoperties > Security and provide the full access rights to the user. or,
Disable the antivirus and retry, it should work. If it is then add the folder path or the application name "func.exe" as an Exception.
One more solution that I figured out today especially when the antivirus is in client mode and linked with its server for policy.
4. You need to whitelist the path in the server policy and after 5 minutes say, Update the Antivirus, restart the Visual Studio and its done.
Same error I also faced due to anti-virus but can't modify anti-virus since it can be changed by IT Security/networking team and process is time-taking & long process. Another workaround is :
Install azure-functions-core-tools via npm
npm install -g azure-functions-core-tools#3
Change Executable & Working Directory in Debug settings for azure Project settings
Working Directory : C:\<Project path>\bin\Debug\netcoreapp3.1
Executable : C:\Users\<username>\AppData\Roaming\npm\node_modules\azure-functions-core-tools\bin\func.exe
I have created an agent iin which I call a dll file so that I can get data from another system eventually..
When I manually run this agent then the call to the dll file works and I get data from it.
When I call this agent from a browser then I get:
Error Description : Cannot create automation object
The security of the agent is on 3.Allow restricted operations with full administration rights.
Any idea why I get Cannot create automation object when running agent from browser?
When you start the agent from browser then the agent runs on Domino server.
So, you need to install automation object's software on this server.
When you manually run the agent then the code is executed on your client. This works because you installed the software necessary for creating the automation object on your client.
I found the same error but in my case everything was working properly until we restored a backup of Windows. The issue was caused because Office had to be reactivated again.
Sometimes this happens too because a corruption of the Word document, so you have to rebuild it.
I hope this could be helpful in future to other people
When I try to debug in Visual Studio I get the error message:
Unable to copy file "C:\Users\Name\Dropbox\Company Name\Development\Product Name 4 - Release Candidate\packages\MahApps.Metro.1.1.2.0\lib\net45\MahApps.Metro.dll" to "bin\Debug\MahApps.Metro.dll". The process cannot access the file 'bin\Debug\MahApps.Metro.dll' because it is being used by another process. Product Name 4 - Release Candidate
How can I fix this error?
This happens all the time in Dropbox. Dropbox does some occasional (very brief) locking of files as it is indexing them, and if you happen to attempt to open a file handle with the write attribute set at the same moment, the program will receive a file I/O exception (this can happen to your own code as well, so if you regularly work in Dropbox, be sure to handle that gracefully).
Try compiling/running it again and see if the problem goes away. If not, then you likely still have an instance of your application running in the background. This can occur if your program ever forks. VS will terminate the original process, but often not forked processes from it. Check task manager to be sure. It will be listed as a background process in Windows 8/8.1
I am using WSPBuilder to develop Sharepoint2007 sites, whenever i try to debug using one of the users that are not System Account, the debugger enters to the breakpoint and waits a step (F10), when i press F10, i get the following exception in the debug output window after pressing F10 on the line having the breakpoint:
A first chance exception of type 'System.Threading.ThreadAbortException'
occurred in XXX.dll
An exception of type 'System.Threading.ThreadAbortException'occurred in XXX.dll
but was not handled in user code The thread '<No Name>' (0xfc4) has exited with
code 0 (0x0).
and i am redirected to a page of sharepoint saying:
Go back to site
Error: Access Denied
Current User
You are currently signed in as: SHAREPOINT\ZZZ
Sign in as a different user
When i try to RUN not to DEBUG with the same user, I don't have this problem.
Also when i try to debug using the System Account (MOSS ADMIN), I don't have this problem ?
How to overcome this problem ?
BTW, i am trying to debug a custom ASPX/CS page installed as a feature on the site.
FYI, it's only for this project not for all projects i have, also it's for all pages in this project not only one page.
For those who are interested, I found the solution:
I created a new project and copied my files to it (of course with recreating features), now it works fine. That means that the project itself is the problem not the IDE, perhaps some of its file are corrupted !
You might want to try and add the user SharePoint\zzz to the WSS_WPG and WSS_Admin groups to see if that gets you around the issue. I assume you are doing the debugging on a single, stand alone install so you could also try and make SharePoint\zzz and administrator.
I wrote a Windows Service using VS 2005 and C# on WinXP Pro SP3. It starts another program which runs to completion and then exits.
The service is installed using installutil and serviceInstaller. It is built release and put into the C:\Program Files\MyService directory. The serviceProcessInstaller Account is set to LocalSystem in it's Properties.
If I set the Log On to Local system I get an 'Access Denied' error (using a try-catch block), but if I set the Log On to my account with the correct password, it runs perfectly.
What am I doing wrong? Any suggestions will be very welcome.
It will be useful to know where the access denied error comes from. Since you say it is from a try/catch block, I assume it is your code that handles it. That would mean that your service is starting just fine, but has problems doing its job.
It could be environment related problem, since the environment for LocalSystem is different than your user account. Also, it could be that the program it starts is not executing properly and it is returning the error.
Without more info, it is just speculation. What is that other program doing? Where is the error occurring? Why don't you debug it and find which part returns the access denied error?
Agreed, it should be on SO. That aside, check your file/folder permission sand ensure System does in fact have the necessary rights. Do the same for the registry keys. The System event log should give you some clues.
Both answers: thanks for the help.
The error orrurs at the Process.Start() call.
The file and directory security shows Everyone has full access to the directories and the executable.
FOUND IT! I had added a user name and password to the ProcessStartInfo object, thinking that it would be useful when the target program tries to get to the database. Oops! When I took that stuff out, the target runs jult like it should.
Thanks again to all who replied. Mea Culpa!