I have a DocFx project folder which contains all the correct files to host the project.
On my laptop, I'm able to use the code docfx docfx.json --serve to host the project on my localhost completely fine. However on my PC it errors out.
I'm syncing my files using GitHub, so the files / file locations are identical.
Also Initially it worked on my PC, then it stopped...
The error I'm getting is this:
[20-10-10 04:54:46.403]Error:System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Windows\System32\docfx_project\obj.cache\build\4t5lswwe.fue\dynp2fa1.gsl'.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
Complete Error Image
Current Directory:
PS C:\Users\aiden\Documents\GitHub\TAFE.2020.S2.SMALL.GROUP.PROJECT\docfx_project>
As you can see, my current directory is the project directory. However the error message states it's trying to pull docfx data files from within' system32. The files it is trying to pull are within' my docfx project.
Since it cannot find the files in system32, it errors out.
Anyone know how or why this is happening??
I had the same problem. I moved the DocFx project around between folders; after that, the problem ocurred. I think, it is something with the cache of DocFx (incremental builds)
I solved it with
docfx docfx.json --force
No idea why, but the version of Docfx (project files) on my laptop were not syncing properly to my PC.
I realized this, deleted the version on my PC (outdated one) and copied it over.
There must have been something messed up in my old Docfx project because as soon as I opened the new one, it worked.
Related
We have two environments on Azure (Same site, same config etc...) All deployment was scripted over ARM Json files and deployment by VSTS.
When I hit the first environment, everything is ok.
But on the other environment, I caught exception. After investigation, it seems Azure does not see my unity config files (XML files in UTF-8). When I open all my files via (App Service Editor (Preview)) Note: I only set a space on the file for update only. After that my web app run well.
At each deployment, I need to go via Azure Portal to edit my Unity.config files to fix my WebApp.
Anyone have an idea about it? And why my first site with the same file, config, deployment working well, but not the second one?
it seems Azure does not see my unity config files (XML files in UTF-8).
Please double check whether the encoding of your config file is UTF-8 before deploying it. You could take following steps to check it.
Open your config file using Notepad.
After clicked File->Save As..., you will see the current encoding of your config file. If the current encoding is not UTF-8, please change the encoding to UTF-8 and save the file.
Latest meteor version 1.4.0.1. All of a sudden it got stuck on Processing files with ecmascript (for... step. Killing and restarting didn't work, neither did rebooting.
What I tried: meteor reset, rebooting, deleting build and cache folders in project's .meteor folder, deleting and reinstalling npm packages. Removing .meteor in my home folder and reinstalling meteor from scratch. Removing packages, both meteor and npm, that I no longer use.
This is something in my project because creating a new meteor project and running it works fine. The project uses React and has a number of components.
Any ideas on how to fix this?
I solved my issue by process of elimination. I saved a .js file in my client/js/lib folder while working on a feature. At some point later I accidentally saved my meteor application's home page in the same folder! Guess I was too tired. Found the folder and then saw the html and a subfolder with meteor-generated scripts. Removed them and everything clicked. My exact steps:
create a new meteor project, copy over package.json and
.meteor/packages files run meteor npm install and then run the
project with meteor
while the project is running start copying over root app folders one
by one, wait for app to recompile before moving on to each folder
my problem surfaced when I copied over the client folder. Meteor said
refreshing client and got stuck there.
I removed the client folder, killed the process (run ps command, kill
-9 [PID] where PID is the process id with the high CPU time.) and then restarted meteor again
created client folder manually and then started copying client/*
items over one by one
that's when I noticed the app_name.html and app_name folder with a
lot of .js files in it!
I removed them and everything works now. Good luck!
You can try running meteor reset command and then running the project again.
I ran into a similar (but different) problem. I am trying to use plotly.js with meteor. I downloaded the plotly.js file and put it into my client/lib directory. Now, when I try to run meteor, I get the same error being described above. I thought plotly.js worked with meteor? If I remove plotly.js (or rename it to a non js file), meteor works fine...so the issue is clearly with plotly.js
I've created an online asp.net app using VS2010 with VB. It has been online and working for over a year. It's on our company's public web server but it's only for employee use. For as long as the site has been active and in use, I have had to made periodic changes to improve performance or to fix bugs; no problem until now. Suddenly, though, VS is throwing an error during the publishing process:
Unable to add 'app_offline.htm' to the Web site. The file 'app_offline.htm' already exists in this Web site.
The IDE is set up to create the site files in a local directory on my workstation machine, and then I copy the files to the server.
The local directory does not contain the app_offline.htm file, so I don't get why the error is saying that it already exists.
It appears that even with this error, all of the files are being properly created, and the site works fine after I copy them to the server, so this is apparently not a fatal error. But it's still unnerving to me to not know why it's doing that, and why just now when it has been fine for over a year.
I would either like to find what's causing the problem and fix it or to find a way to inhibit the process of creating the app_offline.htm file. Anyone have any ideas? No search has turned up any helpful information.
Thanks!
Have you tried removing the file in question from the project, publishing again, then adding it back and publishing?
You can right click on the file(s) and choose "Exclude from project..."
I have an application that I deploy as an executable JAR file. Originally, this JAR file would communicate with a MySQL database but recently I have decided I want to go with SQLite instead. However, while testing I found that I could not access my SQLite database file when running my application from the JAR file.
I'm using the JDBC driver from the following website: http://zentus.com/sqlitejdbc/index.html
Is there a workaround I have to do?
The driver works great while testing in my Eclipse environment, but doesn't seem to work standalone in a JAR file. Any help would be greatly appreciated.
Well, here is such term as "working directory". It is the directory from where your application is started. So, every "relative" path in your application is usually relative to this "working directory".
Now let's return to your problem. When you set the path to a file you can make it either relative, absolute or relative to the JAR inner directory root, depending how you do create the file and set the path.
So, just recheck how paths are set in your application and try to use the relative one, running you application from the appropriate directory.
I am using Visual Studio 2008 and trying to publish a Web Application Project, but it keeps failing when trying to add files in the project. Below is a sample of the message;
Publishing folder JavaScript... Unable
to add 'JavaScript/hoverIntent.js' to
the Web site. Unable to add file
'JavaScript\hoverIntent.js'. The
specified file could not be encrypted.
This happens for image files too. I am lost as to why it is happening. I should add that I am using Windows 7 build 7100, not sure if this is casuing the issue??
Any help greatly appreciated
I know this is an old topic, but I found it when I googled for the same problem.
My solution was to remove the "Encrypt" flag from Windows Explorer for the files listed (Right click -> Properties -> Advanced)
This blog post at BlackMarble is suggesting that you may have the target directory set to use encryption. Sounds like the exception you're seeing is the inability for the VS publish process to handle that.
To get around this problem:
use VS to publish to an intermediate directory. Somewhere on your PC perhaps.
copy the files yourself (with a batch file maybe) to the server
That's a workaround, at least.
Disable windows encrypted file system in cmd with the following:
fsutil behavior set disableencryption 1
Then restart your PC.
When I had this problem on publishing a Visual Studio 2010 web project either to a local folder or to a host, I was stumped. Visual Studio didn't indicate which files or even folders had caused the problem. I wasn't aware there were any encrypted files in the solution and I couldn't find any. I was unable to update my website.
I googled how to find encrypted files but none of the solutions involving efsinfo.exe were appropriate to Windows 7 then I found an example using the cipher command:
https://superuser.com/questions/58878/how-to-list-encrypted-files-in-windows-7
There were a number of different answers to finding the encrypted files. I used the command prompt method.
I opened a command prompt in the root of my application and did:
D:\Data\Code2011>cipher /s:MyWeb >Encryption.txt
I then did a case sensitive search in Encryption.txt for lines beginning E[space] or 'the file is encrypted'
I found two .htc files which were encrypted in a styles subfolder and was able to unencrypt them in the advanced tab of explorer file properties.
The Web then compiled and published OK.
I had this issue as well. I set the source files properties to not be encrypted but that still wasn't working. Turned out that the files were cached in the temporary deployment folder and I had to uncheck encryption there as well. It probably would have worked to delete the temporary deployment directory but the other way worked.