I am working on a Service Fabric application that contains a number of stateless services and a single stateful service. When I publish the first time, everything is fine and it's deployed to my local cluster. After this, if I try to package or publish the app without explicitly stopping it first, I get the following error:
CSC : error CS2012: Cannot open 'C:...\ProjectFolder\obj\x64\Debug\ProjectName.pdb' for writing -- 'The process cannot access the file 'C:...\ProjectFolder\obj\x64\Debug\ProjectName.pdb' because it is being used by another process.'
According to process explorer, the PDB is locked by my own ProjectName.exe. This is the single stateful service in my application.
Why would my exe lock its own PDBs? I could understand if it was Visual Studio doing it.
I see nothing in my own code that should cause this, so I'm assuming it's something in the Fabric code I'm calling.
The PDBs are deployed with the application, but it's the files in the original source directory that are locked - why not the PDBs adjacent to the running code?
Why do I only see this error relating to the stateful service, and not the stateless services?
I suspect this has something to do with the stateful service generating lots of errors on startup, which Fabric may need symbols to properly display.
How can I stop it happening - either using the correct PDBs or not using them at all unless I'm debugging through Visual Studio?
Edit: Raised on github. Current workaround for this:
A current workaround at this point in time would be to restrict the Network Service access to the pdb in the build folder (obj\x64\Debug).
Based on the issue that was raised, it looks like this is now fixed.
"Going to close the issue as we believe both issues have now been addressed by the 5.6 runtime and the 1.6 tooling."
Seems upgrading is now the answer to point 4. If anyone can answer 1-3 I'd be very happy to move the big green tick.
Related
I'm trying to write my first Windows Service in C#. If I follow the MS tutorial to the letter, I can create a simple service with a timer that works and writes to the eventLog. The second I change ANYTHING it will not start with 1064.
I installed the service by calling C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe from the solution's bin\debug folder.
I have uninstalled the service and reinstalled it.
I have used SC DELETE and reinstalled it.
I have rebooted. Nothing works, unless I start a new project from scratch, which fails again when I try to change anything. Does something have to be reset if you change code?
Starting again with baby steps and careful use of the event log I was able to determine that the service could not access a file path which referred to a drive created with a SUBST command (I don't have an E drive on the development machine). I presume this is because the SUBST is not in the service's process, however why that caused the service controller to error on startup I don't know, possibly because the path was accessed from Properties.Settings.Default. The mystery fact remains that a working version stopped working when I only changed the service display name and rebuilt (after uninstalling & reinstalling).
We're trying to run R.net from an ASP.Net webpage in IIS, but encounter the problem that the R engine can't access external libraries. I know this is a common problem, but the typical solutions haven't worked when it comes to IIS (only IIS express from inside VS).
For example, when trying to use 'colorRampPalette' in R which relies on a DLL, the following error message appears:
"Error in inDL(x, as.logical(local), as.logical(now), ...) : unable to load shared object 'C:/Program Files/R/R-3.4.2/library/stats/libs/x64/stats.dll': LoadLibrary failure: The specified module could not be found."
It is not the stats.dll that is the problem, but rather another DLL it references.
Now, using the function in R works fine. Using the function from R.net in VS debugging works fine. However, running it from IIS does not work. Normally, it's just a path variable missing to get it to work, but this doesn't seem to be the case here.
What we've tried:
Ensured that the PATH variable has the necessary folders (i.e. C:\Program Files\R\R-3.4.3\bin\x64 etc). If this was wrong then R.net wouldn't work locally, and I've also verified that IIS doesn't reset the PATH variables which has been pointed out in other sources. When I check the PATH variable from inside IIS the necessary folders are listed.
Checked that the library, home and bin path in R.net is correct when running under IIS.
Ensured that the IIS_IUSRS user has read/write access to the necessary folders and files.
Verified that the R code is correct.
It seems that this is a common problem, but most solutions refer to making sure the PATH variable is correct, which simply isn't enough in this case.
We're running (Amazon web service):
Windows Server 2016 x64,
IIS 10,
R.NET 1.7,
C# 4.5.2,
R 3.4.2
I've also tried on another (non-AWS) server with a similar setup.
Any ideas of what can cause this? Since a lot of people have issues with R.Net and IIS I suspect someone encountered the same problem where the PATH variable wasn't enough?
As mentioned by user2967150, It is not the stats.dll that is the problem, but rather another DLL it references.
After doing lot of research I found that It try to find Rlapack.dll in 'C:/Program Files/R/R-3.4.2/library/stats/libs/x64/ path.
so you just have to copy Rlapack.dll from 'C:\Program Files\R\R-3.4.4\bin\x64 \Rlapack.dll'
to 'C:/Program Files/R/R-3.4.2/library/stats/libs/x64/ .
After this the web Application can access external R libraries.
Note: I assume that your web Application Run locally but creates a problem when you try to run it on IIS.
I was solving same issue. For IIS I did not find the solution. I was also debugging the R.NET code, but solution by setting correct path to R folder did not work.
The solution is created additional layer, which cover running R project (actually create own R server). I used self hosted WCF service,
https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/how-to-host-a-wcf-service-in-a-managed-windows-service
which is practically console application and has benefits application running not in IIS application pool. This solution also cover singleton REngine problem. In case you run the instance or REngine in IIS, there is no posibility dispose it, only by stop application pool. For self-hosted service you can set trigger for restarting application in case memory leak.
During this implementation I discover problem run R.NET again R 3.4.3 in debug mode on console application I get error "The library "..." could not be load", so I used the R 3.4.2. which work nice. 86x installation is required - independent the your application run in 64x/ANYCPU environment.
Have you found any other solution for that?
So, I've had to rework a web app on one of our servers, a legacy app, that needed to get new branding via a common master page, where it previously had none. The page displays ok, but there's a form on it that calls a method in a compiled dll which allows the user to download a document. This throws an error, but the error is vague (mentioning a null reference). We have the source code but I don't have visual studio installed on my machine and even if I did we suspect it may have something to do with the server environment, and the server is not set up to run project files, just compiled web apps. One of my colleagues thought that by removing the dll, the app would just use the cs files and compile that at run time. That didn't work, and another colleague suggested turning debugging on in web.config, which we did, but still no go. He also mentioned that debugging required pdb files, but I don't see any in the source code we have. If I could get this working on the server just using the cs files vs. the dll, I could at least attempt to debug what's going on, any ideas on how to get that working?
There seems to be a good deal of confusion here about how ASP.NET applications work.
First, .CS files are meaningless to IIS. IIS knows about files containing markup. It also knows that the assemblies contained in the bin folder represent the server-side code that handles the incoming requests and generates the outbound responses.
In most cases, when a site is deployed to a production server, the .CS files are not included, because they are just noise on the server, useless file clutter that have no bearing whatsoever on the execution of the application.
Now, you're kind of lucky, because you have the source files there. You can, actually, force a recompilation of the cached assemblies. To do this, open the site's web.config file and add some whitespace (a single space) to the end of the first line. Then save the file. This will cause ASP.NET to clear its cache and rebuild the site.
This isn't guaranteed to get rid of your problem. Like you say, the problem could be somewhere else. What I would strongly suggest is that you download the site in its entirety, install Visual Studio (get a free express edition if you have to), and DEBUG the darned thing.
If you can't run it in a debugger and watch it execute, you're just guessing.
PS If this thing isn't under source code control, get it there, ASAP.
When I try to build my project, it returns the following error:
Error 1 Unexpected error creating debug information file 'D:\Documents\Lance\Documents\School\Capstone\GG\GG\obj\Debug\GG.PDB' -- '' GG
I've recently had the misfortune of having my PC restart on me, due to sudden power supply problems (maybe). This is while the project was building, before this problem started.
When the PC came back online I've noticed that the changes I've made to the program prior to the sudden power down was not saved. And, it won't build anymore.
This worked for me:
Shut down VS.NET
Browse to the project in Windows Explorer
Delete the /obj/ folder.
Delete the project outputs (.dll and .pdb) from /bin (not sure if this step is necessary)
Can't hurt but might help: delete the project outputs from any other project /bin folders in the solution that is having issues (wasn't necessary for me)
Restart VS.NET
Rebuild
http://weblogs.asp.net/ssmith/archive/2003/08/12/23755.aspx
As requested, my comment as an answer:
Try cleaning the solution (under the Build menu in VS).
Since the build was interrupted half-way through by your power failure, the file isn't locked -- the build system is probably just in an inconsistent state (which a Clean Solution should fix).
This happens once in a while in my environment and the problem probably has to do with the PDB file being locked (i.e., I'm guessing the last part of the error message is missing in your post). This is how it looks on my machine:
Unexpected error creating debug information file 'c:\dir\obj\file.PDB' -- 'c:\dir\obj\file.PDB: The process cannot access the file because it is being used by another process.'
In my case, cleaning the solution does not solve the problem and restarting is an overkill, so I usually just copy the full name of the pdb file (from the error) and execute this on the command line:
ren c:\dir\obj\file.PDB *.old
This worked for me: Close Visual studio and open visual studio using Run as Administrator and problem was solved.
Not need to restart or delete the file.
Just rename the file and that is enough. If you try to delete the file it will give an error. Better just rename it & it will work. :)
If you are having this problem with a web application, this can happen in the unusual situation that you have used DebugDiag and created a rule that listens on your project's app pool. Deleting the rule prevented this problem from recurring.
This might happen, for example, if you followed these instructions for diagnosing a stack overflow exception in IIS.
If you are working on VM with two user, make sure the other user has not attached all the process while debugging.
Cons of restarting VS:
Clipboard will be lost
Redo/undo will be lost
Files open will be lost
You will loose the tempo
Solution:
Give your Assembly a new name. No cons. Except you will have to rename your assembly back to its original name when you are ready for final deployment. And I think anyone can find how to make it work for the last time :)
Sometimes all the files from \bin folder are used by a running process, i.e. web site on IIS or windows service run automatically after build. In such cases turning off the service or stoping IIS app pool for specific site should also help (like in my case)
Sometimes I run into this problem, when compiling the same project for (very) different targets:
VS2008 and net35
VS2017 and net462
dotnet core 2.0
My guess is, that either bin and/Or obj directory are used by the compiler, but the outputs are not compatible (of course). Solution clean from VS indeed helps.
Often we specify different dll names for the output (e.g. mylib.dll, mylib35.dll) and the issue never happened on those projects.
I'm working on a moderately sized WebForms project. Due to the peculiarities of management here, I have to upload the site to a remote server in order to test (no localhost testing). I'm using the 'Publish' command in Visual Studio 2008. Sometimes, it even works. Most of the time, I inexplicably get a "publish failed" in the bottom left corner, with no further details.
The few googled articles/forum posts I read suggested making the target local folder for the publish operation readable/writable for everyone. Doesn't help.
Is there are way to get further details as to WHY a publish fails in VS2008, and if not, is there a better way of doing these deployments? I'm spending more time building/pushing to the web server than actually debugging.
It's worth checking the output window. I've just had a publish fail because I had deleted an image outside of VS so VS was complaining that the image couldn't be found, but this information was only displayed in the output window.
See this link for more information:
http://ericfickes.com/2009/08/find-out-why-visual-studios-publish-fails/
It happens to us when there is an error in markup (!). Bad thing is that VS will just swallow the error and just tell you Failed.
What I suggest is to run your publish from command line using MSBuild. It's not that straightforward but it works (once you get into it).
I've since discovered that the reason for these particular publish failures was due the "Delete Existing Files" option being checked. Using Visual Studio 2008 under a non-administrative account on Windows Vista could cause a permissions error while attempting to delete the existing files. The publish would fail silently after encountering a file that Visual Studio had insufficient access to delete. Once the files were deleted manually outside of Vidual Studio, the publish functioned normally.
I have not had this issue with Windows 7; I assume the UAC changes in Windows 7 fixed the problem.
I mostly work with Web Forms, and I encounter this problem daily.
It seems to me that publish fails when it fails to delete a file it is trying to replace. Even if I don't have any files open, it still fails sometimes. Not sure why.
Not only VS publish fails very often, it is painfully slow as well.
I just publish to empty local directory and use separate FTP client to upload files. It's more work, but works.
This is probably not the case for you, but I've seen this happen when I'm publishing a web site. If the app_offline.htm file is not excluded from your project (if you use this file), the publish will fail.
Same happened to me.. what I did was include images files that was not included in the project and delete images that were not used.
After struggling with a similar issue for about 30 mins with no clue as to what was causing it closed down VS and reopened my project. Started working fine. No idea why but it worked.
You should always stop the IIS instance running on the machine your are publishing to. Google the word "iisreset". Other hosting providers like DiscountAsp and Arvixe offer you tools to "Stop" and "Start" your app pool on their IIS remotely. This is very necessary because IIS may have locked some files as "in use", so your publish fails when it tries to write over them. When your publish is complete, then just restart IIS (or press "Start" from a web tool if you're using a 3rd party hosting provider).
When all else fails, check your "Output" window (the tab to the right of your "Error List" at the bottom of Visual Studio). Scroll through all of it after a failed publish and look for anything that says "Unable to add". If you keep seeing the same "Unable to add" errors on the same publish, then ftp into the folder, delete the the problematic files manually, and try publishing again.
I got this when my ProjectName.Publish.xml file was read-only. Once I checked the file out of source control, I no longer got the error and could publish.
Just to add to this thread, I found that, for some bizarre reason, only the Mercurial files were being published to the server, everything else just wasn't being copied across.
Another strange thing was that only the Debug configuration was available; Release was nowhere to be seen.
After reading other threads around S.O., I found that there were many for VS 2010 and 2012, but not much to cover the same problem with 2008.
The fix, I found, was to delete the [solution].suo file and then attempt a publish. That seemed to do the job, though it took a long time to complete.
What I found and work in my case. It is to use a different version of VS.
I recently had the problem, the solution works perfectly in VS2015 build, compile and tested.
However, when I try to publish was failing silently.
So, I closed the solution and open it with VS2017 that use the same file structure for the projects/solutions. Then rebuild it and publish without any problems.
I believe it could be VS related and it is complicated to debug.
This is a workaround if you work with multiple Vs instances in your local machine.