I downloaded the latest and get the following error though this dll does not appear to be on my computer. I unblocked the zip yet I still get this error:
I resolved it my deleting all the old config data in the environment variable, %APPDATA%\MscrmTools\XrmToolBox .
Related
how to solve this error?
bundling failed: Error: Unable to resolve module ../../assets/images/background.png from src\IntroScreen\IntroScreen.js
Just check this folder with your explorer yourProject/assets/images/background.png is there any background.png exist ?
It's because maybe in the background your server was running and you dragged the image or folder into the assets folder while running the server. Since the newly added file address hasn't been stacked to memory or you can say the background hasn't been noted you already copied the image. So it throws this error.
So now you close the server then you restart it again or rerun npm then the server or interpreter will note that and put it on memory. Then you will not see this error.
We maintain a Debian repository for an app and all .deb files are stored on a s3 bucket.
We wrote a script to upload the files and update the Packages.gz file. All went fine until one of the developers found deb-s3 and tried using it.
After the first package upload we started getting this error message:
W: Failed to fetch s3://s3.amazonaws.com/myapp/dists/test/main/binary-amd64/Packages Hash Sum mismatch
I've tried to restore an old version of our Packages.gz file with no success. I've searched for this error and removing the /var/lib/apt/lists/ does not work either.
What would deb-s3 do that could break our entire repo?
Looks like deb-s3 creates a Releases file under dist/test and that conflicts with Packages.gz.
Removing the Release file restored our repository back to what it was.
I got this err msg while running my WindowsCE app:
...and so I copied NETCFv35.Messages.EN.wm.cab from my PC to my handheld, and tried to run/install that cab file on the handheld. I got:
So then I tried the same with NETCFv35.Messages.EN.cab. When I ran it on the handheld, it told me that it had already been installed:
...but I went ahead and "reinstalled." I'm not sure its default installation location, though, is the right place:
...so I copied it over again to the folder on the handheld where my .exe resides (NETCFv35.Messages.EN.cab had been deleted out of there after reinstalling). This time I made sure to install it into that same folder, rather than the seemingly random location it chose the first time:
Still, though, running the app shows me the same old "Which way did they go, George?" err msg about not being able to show me error messages (first screamshot above).
This makes me feel kind of Grimm, to the point where I'm thinking this is a pretty revoltin' development (no pun intended).
What do I need to do to be able to see the hidden err msgs?
UPDATE
This is what I got when I unpacked SYCCFA~1.001, renamed it System.SR.dll, and tried to add it as a reference to the project (it claims that it is not a .NET assembly...???):
I tried the same thing with NETCFv35.Messages.EN.wm.cab, with the same results (it looks like the same file - same date, same size...so why the name diff?)
The error messages are in a single file called "System.SR.dll". The CAB simply installs that and puts it into the GAC. You get an "already installed" error because it sees it in the registry, though it doesn't mean the file is actually there.
You can simply extract the DLL from the cab with a zip extractor (I use WinRAR, but whatever). For example, If I open this file:
C:\Program Files (x86)\Microsoft.NET\SDK\CompactFramework\v3.5\WindowsCE\Diagnostics\NETCFv35.Messages.EN.cab
It has a few things in it. SYCCFA~1.001 is the DLL. Pull it out, rename it to System.SR.dll and add it as a reference in your project. Studio will deploy it when you run and boom, you're cooking with butter.
I'm having some strange issues with WiX on my local machine. The problem is intermittent, but after a few rebuilds of the solution, the WiX project starts throwing ICE validation errors.
If I go into my AppData\Local\Temp folder and delete all the temporary folders that contain the MSI, the solution compiles again. A short while later, the problem starts happening again. Having to keep clearing down the temp folders isn't a sustainable or satisfactory solution.
Has anyone else encountered this issue? The validation error codes seem to always be a combination of ICE30, ICE38, ICE64 and ICE91
Update:
As requested, here are the entries from the most recent failure:
error LGHT0204: ICE38: ICE Internal Error 1002. API Returned:
1615. error LGHT0204: ICE38: Error 2235: /OU.AppFramework.Includes.msi, _Profile, UPDATE Directory SET
_Profile=0 error LGHT0204: ICE64: ICE Internal Error 1001. API
Returned: 1615. error LGHT0204: ICE64: Error 2242:
OU.AppFramework.Includes.msi, _Profile, ALTER TABLE Directory ADD
_Profile SHORT TEMPORARY HOLD error LGHT0204: ICE91: ICE
Internal Error 1001. API Returned: 1615. error LGHT0204: ICE91:
Error 2242: OU.AppFramework.Includes.msi, _Profile, ALTER TABLE
Directory ADD _Profile SHORT TEMPORARY HOLD
Interestingly, this failure occurred before I left the office last night, and the solution compiled OK when I came in this morning. As it seems to centre on the temp directory where the MSI is build by WiX, could it be the build process locking the file?
Update 2:
And now we're back to over 600 errors, mostly repetition of this error:
error LGHT0204: ICE30: ICE Internal Error 100. API Returned: 1615.
error LGHT0204: ICE30: Error 2235: AppFramework.Includes.msi,
_ICE30SFN, SELECT Directory_Parent, Directory, DefaultDir, _ICE30SFN, _ICE30LFN FROM Directory WHERE
Directory.Directory=? AND Directory_Parent<>?
Update 3:
The problem still exists even after trying the suggestion by #limpan. There are a couple of warning given by light that are caused by the MSI output folder being locked when light tries to access the MSI:
Warning 549 The directory '\AppData\Local\Temp\2opu3hxf' is in use and cannot be deleted. light.exe
Try adding <RunWixToolsOutOfProc>true</RunWixToolsOutOfProc> to your WiX project file.
We've had the same issue for a while, and tried various workarounds including deleting the temporary files and setting the msbuild environment variable. These all appeared to work for a while, but eventually (sometimes after a few days) the problem would come back again.
I noticed that on my machine devenv.exe was the process that was locking the files that light.exe was trying to delete. I also stumbled across an unrelated thread which mentioned this project setting to make the WiX tools run out of process. I thought it could be worth a try and it appears to have cured the problem for us (so far...)
I had this issue as well and solved it in my environment.
Short answer:
Add the environment variable MSBUILDDISABLENODEREUSE=1 and restart Visual Studio
Long answer:
There was a warning during build that I first didn't see since I was too focused on the error:
Failed to delete temporary directory: C:\Users[username]\AppData\Local\Temp\5[uniqueFolderName] light.exe
I tried to remove the folder manually, but it was in use by another process.
It turns out that a lot of MSBuild.exe processes are started during build and then not closed again.
You can read more about the reason for that and what you can do to change that behavior in Stack Overflow question msbuild.exe staying open, locking files.
This thread: it and the solution in this thread:
I hope this answer can help someone else.
For ICE30: ICE Internal Error 100. API Returned: 1615, please try this and see if it works:
Close all instances of Visual Studio (may be just the one that matters but just in case)
Go to C:\Documents and Settings\\****user id****\\Local Settings\Temp\.
Clear all the folders that look like this .. 's12qgaks'. Basically it contains the MSI files
Open the solution and recompile.
Good luck!
I too had faced same the issue. In project properties, go to Tool Settings and click Suppress ICE validation.
For me MSBUILDDISABLENODEREUSE=1 (or /nr:false on command line) did not solve the problem.
But <RunWixToolsOutOfProc>true</RunWixToolsOutOfProc> did its job done.
I had the same issue. It turned out to be my Anti Virus software (OfficeScan) It had the intermediate files created by Light.exe locked and the validation process failed. Excluding the temp folder from virus scan or turning off ICE validation is not an acceptable solution.
If anyone has a better solution. I would like to know.
We have a .net web application running in fedora 6 under Apache & mono 1.1.18 version. So long it was working good. Suddenly I'm getting the following Server Error in some of the pages,
Server Error in '/' Application
Compilation Error
Description: Error compiling a resource required to service this request. Review your source file and modify it to fix this error.
Error message:
(0,0) : error CS0006: Cannot find assembly `/tmp/apache-temp-aspnet-0/383ed40f/shadow-J7sRQf'
But please note, rest of the pages are loading properly. I know it has something to do with JIT compilation, but why it is happening on some specific pages. Also the error 'Cannot find assembly -----/shadow-J7sRQf' is something suspicious. The same error is displayed across all the browsers all the time.
I have not restarted apache or rebooted the system, as I'm not sure whether this error will occur again and i want to root cause it instead of just ignoring it. i didn't find anything on the httpd log also. I tried to Google it, but was unlucky to find anything specific. Can anyone help me on this? thanks in advance.
Wow, mono 1.1.18 is really old!
If I were you, I would try to stop apache and clean everything in the temporary compilation directory /tmp/apache-temp-aspnet-0/
This should force mono to re-generate everything in this directory.
Then, restart apache and see if it helps.