I checked out
http://code.google.com/p/flashdevelop/
In pre Build there is
SubWCRev "$(SolutionDir)\" "$(SolutionDir)FlashDevelop\Properties\AssemblyInfo.cs.rev" "$(SolutionDir)FlashDevelop\Properties\AssemblyInfo.cs"
I changed SubWCRev to "c:...\SubWCRev.exe" because it's not in path env variable. But I got
"subwcrev ... exited with code 6."
Error code 6 means "SVN Error" as seen in the source code of SubWCRev.
That means that the status couldn't be fetched for some reason.
Maybe one of the files is opened in another app, the folder is read/write protected, ...
Or maybe the version of SubWCRev is not the same as your svn client with which you checked out the working copy - in that case the wc format may not be the same.
In my personal experience, "subwcrev ... exited with code 6." error occurred when I haven't added folders/files to the svn. After adding required folders/files to the SVN Repository this error is resolved.
Related
When I try to ADD a REFERENCE to any Visual Studio project...I am suddenly getting the following exception:
Error HRESULT E_FAIL has been returned from a call to a COM component
This happens across ALL projects regardless of whether they are source-controlled (or not)
SIDE NOTE:
I did recently install Xamarin on a SEPARATE PROJECT in another TFS SOLUTION
WHAT I'VE DONE SO FAR:
Delete all *.suo files
Delete all *.user files
Wiped the TFS Workspace & done a FORCE GET
Nothing has worked
The FIRST TIME you get this error message you'll get a window with a reference to the following file:
ActivityLog.xml: This file contains information about the underlying error.
If you ignore the message & click away from the initial dialog, THE ERROR GETS SUPPRESSED and is replaced with:
Error HRESULT E_FAIL has been returned from a call to a COM component.
If you look in this file you will see the error. This particular exception was was caused by:
Microsoft.visualstudio.shell.interop.IVsReferenceManager2
Within the Microsoft.VisualStudio.Shell.Interop.11.0.dll library.
This post helped me solve the issue!
THE FIX IS:
Open "Developer Command Prompt for VS 2017" as an Administraor
CD into "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\PublicAssemblies"
Run "gacutil -i Microsoft.VisualStudio.Shell.Interop.11.0.dll"
After a restart, it all worked well.
I am doing some work on cordova-windows (https://github.com/apache/cordova-windows), which is using AppVeyor for testing on Windows. One of the things that was missing, were tests with Visual Studio 2017 (only VS2015 was used to test before). So I added those and it works like a charm - mostly.
Unfortunately we now have a very strange test failure:
https://ci.appveyor.com/project/ApacheSoftwareFoundation/cordova-windows/build/1.0.458
Started
Creating Cordova Windows Project:
Path: testcreate 応用
Namespace: com.test.app
Name: 応用
Windows project created with cordova-windows#5.1.0-dev
Building project: C:\projects\cordova-windows\testcreate 応用\CordovaApp.Windows10.jsproj
Configuration : release
Platform : x64
Patching 10 in prebuild event...
Injected base.js reference to the www/index.html
Removing /( *)(<script\s+(?:type="text\/javascript"\s+)?src="\/\/Microsoft.WinJS.2.0\/js\/base.js">\s*<\/script>)(\s*)/ from www/index.html
Removing /( *)(<script\s+(?:type="text\/javascript"\s+)?src="\/\/Microsoft.Phone.WinJS.2.1\/js\/base.js">\s*<\/script>)(\s*)/ from www/index.html
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\build\windows\release\x64\win10\CordovaApp.Windows10_1.0.0.0_x64.appx
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\build\windows\release\x64\win10\Upload\CordovaApp.Windows10_1.0.0.0_x64.appx
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0_Test\CordovaApp.Windows10_1.0.0.0_x64.appxbundle
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0\CordovaApp.Windows10_1.0.0.0_x64.appxbundle
CordovaApp.Windows10 -> C:\projects\cordova-windows\testcreate ??\AppPackages\CordovaApp.Windows10_1.0.0.0_x64_bundle.appxupload
Your package has been successfully created.
Building project: C:\projects\cordova-windows\testcreate 応用\CordovaApp.Windows10.jsproj
Configuration : release
Platform : x86
Patching 10 in prebuild event...
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(2975,5): error MSB3231: Unable to remove directory "build\windows\bld\PackageUploadLayout\". The process cannot access the file 'Default.rd.xml' because it is being used by another process. [C:\projects\cordova-windows\testcreate ??\CordovaApp.Windows10.jsproj]
C:\projects\cordova-windows\testcreate 応用\cordova\node_modules\q\q.js:155
throw e;
^
Error: C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe: Command failed with exit code 1
at ChildProcess.whenDone (C:\projects\cordova-windows\testcreate 応用\cordova\node_modules\cordova-common\src\superspawn.js:169:23)
at emitTwo (events.js:106:13)
at ChildProcess.emit (events.js:191:7)
at maybeClose (internal/child_process.js:920:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:230:5)
The relevant part is this:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(2975,5): error MSB3231: Unable to remove directory "build\windows\bld\PackageUploadLayout\". The process cannot access the file 'Default.rd.xml' because it is being used by another process. [C:\projects\cordova-windows\testcreate ??\CordovaApp.Windows10.jsproj]
This is not happening when I run the tests locally, meaning I can in no way reproduce what is going on here.
Any idea what process could block this Default.rd.xml file or build\windows\bld\PackageUploadLayout\?
How can I find out in a CI environment like AppVeyor?
Update:
Investigated a bit more by adding /clp:Verbosity=normal to the msbuild calls that are executed.
It runs a similar msbuild call 3 times (once per architecture). The first one succeeds, but during the second one the failure occurs. Makes sense as in the first iteration the folder doesn't exist yet, which it confirms with this output: Directory "build\windows\bld\PackageUploadLayout\" doesn't exist. Skipping..
The last output before the failure then is Removing directory "build\windows\bld\PackageUploadLayout\". which matches what we get in the error message. No indicator why the removing doesn't work though.
Super strange: With /clp:Verbosity=detailed added to the msbuild call, the build actually succeeds! My guess: Because the output takes time, whatever is having a lock on the folder or file releases it.
This is not exactly an answer, but rather investigation report. It is just not enough room comments to describe it. Here is what I did:
forked your repo
created AppVeyor project
added RDP
connected with RDP
installed procmon
added filter to monitor objects which path ends with bld\PackageUploadLayout\Properties\Default.rd.xml
run npm test manually from CMD
When the same error happened I see this:
I am not sure I understand why msbuild failed this way. I opened SHARING VIOLATION event, switched to process and see this:
What catches my eye is that msbuild version is 14. Should be 15 on Visual Studio 2017 image. We have version 14 installed for specific scenarios but default one is 15 (run where msbuild and you will see C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe). I am not sure where this path is set in your scripts, but I feel if you make it run correct msbuild version this may help.
I’m having an issue with ftp.SyncLocalDir when I have an open file on the local directory.
I’m using the example from http://www.example-code.com/vbnet/ftp_syncLocalTree.asp with a few minor changes. It has been working fine for a few days and then has stopped working.
I’ve found that one of the files is open on the local directory. Looking through the http://chilkatforum.com/ forum I see that one of the answers stated that
“Chilkat will detect errors that are likely permission/access errors and will continue with the remainder of the download.”
This is not happening for me. Looking at the last error text it states that the file is used by another process. Not other files get synchronized.
Is the something else I need to add to the code to force it to continue after the error?
Below is the last error text.
Thanks,
Steve
ChilkatLog:
SyncLocalDir:
DllDate: Dec 5 2014
ChilkatVersion: 9.5.0.46
UnlockPrefix: *********
Username: *********
Architecture: Little Endian; 32-bit
Language: .NET 4.0
VerboseLogging: 0
commandCharset: ansi
dirListingCharset: ansi
localDirPath: Q:\TEST
mode: 2
ProgressMonitoring:
enabled: yes
heartbeatMs: 0
sendBufferSize: 65536
--ProgressMonitoring
downloadDir:
getFile2:
localFilename: Q:\TEST/LINE_6 _13.csv
Replacing existing local file
openForReadWriteWin32:
Failed to open file (2)
localFilePath: Q:\TEST\LINE_6 _13.csv
currentWorkingDirectory: H:\Code In Progress\LLS\Gen 3 Test And Crimp
w-network\VB Code\trunk\FTP Syncronize\bin\Debug
osErrorInfo: The process cannot access the file because it is being us
ed by another process.
localWindowsFilePath: Q:\TEST\Line 6\LINE_6 _13.csv
--openForReadWriteWin32
--getFile2
Failed to download file
failedFilename: /LINE_6 _13.csv
--downloadDir
Failed.
--SyncLocalDir
--ChilkatLog
Please try this new build for the .NET 4.0 Framework:
32-bit Download: http://www.chilkatsoft.com/download/preRelease/ChilkatDotNet4-9.5.0-win32.zip
64-bit Download: http://www.chilkatsoft.com/download/preRelease/ChilkatDotNet4-9.5.0-x64.zip
The feature for continuing past permission/access issues had to do with issues on the remote server as opposed to the local filesystem. This new build should now also do the same for local permission errors. It will be noted in the release notes for Chilkat version 9.5.0.47 when released (soon).
If you have trouble, please post the LastErrorText using this new build.
So I downloaded and installed Microsoft Accelerator v2 to use ParallelArrays. I have referenced it in my project but when I try and execute the code from the module in a script file I get:
"The namespace 'ParallelArrays' is not defined
I have followed the instructions on this post:
Microsoft Accelerator library with Visual Studio F#
I've added a reference to the managed version "Microsoft.Accelerator.dll" to my F# project and then added the native "Accelerator.dll" as an item in my solution and set it's 'Copy To Output Directory' to Copy Always.
Still getting the FSI error and inline error in my script file on the '#load ...' line, however the solution builds fine, and no error in the module file.
Any ideas on what I'm missing? I'm sure it's something stupid.
Thanks,
Justin
UPDATE
I tried mydogisbox's advice, which got rid of the error above, but now when I run the code in the .fsx file I get this error instead:
--> Referenced 'F:\Work\GitHub\qf-sharp\qf-sharp\bin\Debug\Microsoft.Accelerator.dll' (file may be locked by F# Interactive process)
[Loading F:\Work\GitHub\qf-sharp\qf-sharp\MonteCarloGPU.fs]
error FS0192: internal error: F:\Work\GitHub\qf-sharp\qf-sharp\Accelerator.dll: bad cli header, rva 0
UPDATE 2
So the bad header error has dissapeared, but now I get this instead:
Microsoft.ParallelArrays.AcceleratorException: Failure to create a DirectX 9 device.
at Microsoft.ParallelArrays.ParallelArrays.ThrowNativeAcceleratorException()
at Microsoft.ParallelArrays.DX9Target..ctor()
at <StartupCode$FSI_0002>.$FSI_0002_MonteCarloGPU.main#() in F:\Work\GitHub\qf- sharp\qf-sharp\MonteCarloGPU.fs:line 14
Stopped due to error
I found this thread on MSDN however the answers proposed as fixes on that thread barely even relate to the question.
http://social.msdn.microsoft.com/Forums/vstudio/en-US/98600646-0345-4f62-a6c5-f03ac9c77179/ms-accelerator?forum=csharpgeneral
My Direct X version is 11, and I imagine that will suffice, however I tried installing DX9 however, it tells me that a newer version is detected therefore cant install.
There are special directives for referencing dlls from fsi. The #load directive loads the .fs file only. You need to use the #r directive to reference the file. You can either use the full path of the file or you can use #I to include the path to the file. More details here. Keep in mind that fsi is completely independent of your project, so all references in your project must be duplicated in fsi for it to access the same types.
My VS2010 database deploy is failing on my build server, which has SQL Server 2008 R2 installed on it. Here's the output that's relevant:
Creating Acme.Database...
D:\TeamCity\BuildAgent\Work\da2fc5ebd5805d44\src\Acme.Database\sql\Acme.Database.sql(30,0): Error SQL01268: .Net SqlClient Data Provider: Msg 5133, Level 16, State 1, Line 1 Directory lookup for the file "C:\Program Files\Microsoft SQL Server**MSSQL10.MSSQLSERVER**\MSSQL\DATA\Acme_Database_log.ldf" failed with the operating system error 3(The system cannot find the path specified.).
D:\TeamCity\BuildAgent\Work\da2fc5ebd5805d44\src\Acme.Database\sql\Acme.Database.sql(30,0): Error SQL01268: .Net SqlClient Data Provider: Msg 1802, Level 16, State 1, Line 1 CREATE DATABASE failed. Some file names listed could not be created. Check related errors.
An error occurred while the batch was being executed.
The actual path is here:
C:\Program Files\Microsoft SQL Server**MSSQL10_50.MSSQLSERVER**\MSSQL\DATA\Acme_Database.mdf
The only reference to the path I could find in the database project was in the root folder, a file called:
PRIMARY.Acme_Database.sqlfile.sql
It includes an ALTER DATABASE statement that I changed to use the _50 path, but this did not fix the issue.
I'm not sure why the db project needs to know where the actual database MDF file is located in any case - I would have thought it could just connect to it vis TSQL, but in any case I can't get the project to deploy with this error and would appreciate any help.
Turns out if you specify a "file" in Schema Objects\Database Level Objects\Storage\Files (use Add Item, File) the values specified in the path override those looked up from the Server. If you must specify them use the variables from sqlcmdvariables $(DefaultdataPath)$(Databasename) to fill things out.
Take a look at the default file path on the server itself.
Screencast: http://screencast.com/t/OWM5ODFjZj
The fact that you don't have a path specified could likely be the issue.
[Update]
The reason I suggest this is that during the creation of the deployment script, if you have not specified the settings in the Project Settings -> Deployment tab, the DefaultDataPath is looked up from the target server's path.
I don't know anything about TeamCity really so this may be a stupid question, but how are you doing the deployment? It looks like the MSBuild deploy task for a DB project can take a property that gives the data path:
http://www.codewrecks.com/blog/index.php/2009/10/06/deploy-a-database-project-with-tfs-build/
Can you set the path that way?
I had the same error, but a different solution.
For me everything was correct (as far as I can tell), but the generated deploy script set the path variables before the databasename variable - resulting in a reference to a variable that did not exist. I updated Database.sqlcmdvars to hardcode the database name value - not best practice, but a sufficient workaround for my needs.