Build can not find solution - build

I tried to configure an automatic build in Visual Studio 2013. I set 1. Solution to build = C:\Users\xxx\Source\Repos\Project\AlarmPrinter\AlarmPrinter.sln (this is the exact path to the solution) under BuildConfiguration - Process. But I get following exceptions.
Exception Message: The project file 'C:\Users\xxx\Source\Repos\Project\AlarmPrinter\AlarmPrinter.sln' was not found. (type FileNotFoundException)
Exception Stack Trace: at System.Activities.Statements.Throw.Execute(CodeActivityContext context)
at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager)
at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)
Unable to restore NuGet packages. Details: The directory name is invalid
TF270003: Failed to copy. Ensure the source directory C:\a\bin exists and that you have the appropriate permissions.
How can I configure the build correctly?

Related

Specflow plugin failure for Visual Studio 2017

I have both VS 2015 Update 3 and VS 2017 15.7 installed on my machine. After installing new VS2017 I downloaded the specflow for visual studio 2017 to install in VS 2017 Enterprise (15.7)
I am able to build the code after I do getlatest but not when I edit. When I try to Add New Item a new feature file I am not able to do this using VS 2017 I can't see the SpecFlow feature template, or, indeed, any SpecFlow template. I get following error when I am trying to build after I edit/Add a line in the feature file -
Below is the error in .cs file for respective feature file :-
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.InvalidOperationException: Collection was modified; enumeration operation may not execute.
at System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource resource)
at System.Collections.Generic.Dictionary`2.Enumerator.MoveNext()
at System.Linq.Enumerable.WhereSelectEnumerableIterator`2.MoveNext()
at BoDi.ObjectContainer.NamedInstanceDictionaryRegistration.Resolve(ObjectContainer container, RegistrationKey keyToResolve, ResolutionList resolutionPath)
at BoDi.ObjectContainer.ResolveObject(RegistrationKey keyToResolve, ResolutionList resolutionPath)
at BoDi.ObjectContainer.Resolve(Type typeToResolve, ResolutionList resolutionPath, String name)
at TechTalk.SpecFlow.Generator.UnitTestConverter.FeatureGeneratorRegistry..ctor(IObjectContainer objectContainer)
--- End of inner exception stack trace ---
t System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at TechTalk.SpecFlow.Generator.TestGeneratorFactory.CreateGenerator(ProjectSettings projectSettings)
at TechTalk.SpecFlow.VisualStudio.CodeBehindGenerator.Actions.GenerateTestFileAction.GenerateTestFile(GenerateTestFileParameters opts)
specflowvisual-studio-2017
Others in my team are able to build the latest code as well as they are able to edit feature file and build it successfully. How do I fix this issue on my local? I don't see any other updated version of SpecFlow where this issue got fixed. Please advise.

Failed to create Release artifact directory (Access to the path 'C:\agent\_work\r1\a\NUL' is denied.)

Lately we face an annoying problem with our build agents (2 seperately installed machines running Windows 2016) with the VSTS build agent installed. When we run del "\\?\%CD%\nul" (see Super User) it works for a couple of builds and then appears again.
How and why is this file created and how can we make sure the build agent doesn't break?
Stacktrace below:
Failed to create Release artifact directory C:\agent\_work\r1\a with an exception
Microsoft.VisualStudio.Services.Agent.Worker.Release.Artifacts.ArtifactDirectoryCreationFailedException: Failed to create Release artifact directory 'C:\agent\_work\r1\a'. ---> System.UnauthorizedAccessException: Access to the path 'C:\agent\_work\r1\a\NUL' is denied.
at System.IO.Win32FileSystem.DeleteFile(String fullPath)
at System.IO.FileInfo.Delete()
at Microsoft.VisualStudio.Services.Agent.Util.IOUtil.c__DisplayClass26_1.b__0(FileSystemInfo item)
at System.Linq.Parallel.ForAllOperator`1.ForAllEnumerator`1.MoveNext(TInput& currentElement, Int32& currentKey)
at System.Linq.Parallel.ForAllSpoolingTask`2.SpoolingWork()
at System.Linq.Parallel.SpoolingTaskBase.Work()
at System.Linq.Parallel.QueryTask.BaseWork(Object unused)
at System.Linq.Parallel.QueryTask.RunTaskSynchronously(Object o)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot)
--- End of inner exception stack trace ---
at Microsoft.VisualStudio.Services.Agent.Worker.Release.ReleaseFileSystemManager.EnsureEmptyDirectory(String directoryPath, CancellationToken cancellationToken)
at Microsoft.VisualStudio.Services.Agent.Worker.Release.RetryExecutor.Execute(Action action). Retrying the creation of Release artifact directory.
The cause of this problem in our case was not related to the build agent. It was a sub-module of a test-runner we use (testcafe) that creates the file. The wrapper that calls this module passes NUL as the name of the log file... and this is not handled correctly further down the line.

MSB4018 The "ResolveComReference" task failed unexpectedly

I am currently trying to upgrade our c++ mfc solution from visual studio 2010 to a visual studio 2013 solution. When i try to build it i get the error MSB4018 The "ResolveComReference" task failed unexpectedly. I enabled fusion logging and this is what it tells me:
=== Pre-bind state information ===
LOG: DisplayName = System
(Partial)
WRN: Partial binding information was supplied for an assembly:
WRN: Assembly Name: System | Domain ID: 1
WRN: A partial bind occurs when only part of the assembly display name is provided.
WRN: This might result in the binder loading an incorrect assembly.
WRN: It is recommended to provide a fully specified textual identity for the assembly,
WRN: that consists of the simple name, version, culture, and public key token.
WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue.
LOG: Appbase = file:///C:/Program Files (x86)/MSBuild/12.0/bin/
LOG: Initial PrivatePath = NULL
Calling assembly : Microsoft.Build.Tasks.v12.0, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. ===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Program Files (x86)\MSBuild\12.0\bin\MSBuild.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/Program Files (x86)/MSBuild/12.0/bin/System.DLL.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/MSBuild/12.0/bin/System/System.DLL.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/MSBuild/12.0/bin/System.EXE.
LOG: Attempting download of new URL file:///C:/Program Files (x86)/MSBuild/12.0/bin/System/System.EXE.
I understand that msbuild has been moved, but i dont understand why it is trying to find System.dll in the msbuild path, how can i make it look for it in its proper location?
Edit:
I have now also tried upgrading to visual studio 2012 which worked without bigger problems and I did not run into the same problem. However i noticed that when running devenv /upgrade (with vs2013) it seems to completely change everything under vc++ directories (it stayed unchanged when upgrading to vs2012). Could this have something to do with this issue?
Edit2:
Tried to build the project in vs2013 after upgrading it to 2012 (without running devenv /upgrade), this also didnt work so I guess the problem is not related to that...
After enabling diagonostic build output i found that it was 3 broken COM references in the project that where failing to load. Removing these references solved the building issue. These where only showing up as warnings in vs2010 but resulted in MSB4018 in vs 2013 for some reason.
This is your problem:
LOG: Appbase = file:///C:/Program Files (x86)/MSBuild/12.0/bin/
Fix the base folder in your build system if you really need it to point to another filder. However it would probably be better to redo you build system targeting 2013 instead of patching the 2010 version.

Exe built using pyinstaller on a Django with pylucene app giving JVM error

I am getting an error:
"Error occurred during initialization of VM
Unable to load native library: Can't find dependent libraries"
The error arises when I try to execute my exe file.
I have created exe file through pyinstaller on a django application. Application uses pylucine library. I think it may be the issue of error.
How to fix the error?
Since I can't be certain given you've provided very few details here is a shot in the dark to help solve your problem:
First, try removing the jvm.dll file that gets packaged with the pyinstaller -D youmodule.py command (for now work with the directory command rather than -F option). The reason why is here.
With that jvm.dll file gone, you should start seeing the actual error code - and with that the java class or dependency that isn't being loaded.
If it's a java class that isn't being properly loaded then you know instantly it must not be correcly represented in the classpath environment variable and you should do everything in your power to make sure it is:
e.g.: os.environ['CLASSPATH'] += 'the/path/to/the/jar'
Otherwise, consider bulking up your question with more details, especially if you can get a more meaningful error output.
I had the same error trying to run a .exe built with PyInstaller through wine.
My problem went away by adding C:\Program Files\Java\ [your jdk version here] \jre\bin\server to the PATH environment variable in wine - I suppose it might be the same in Windows.
It also reappeared if I tried to build with C:\Program Files\Java\ [your jdk version here] \jre\bin\server in my PATH, so I had to build without it and then append it before running it (I have no explanation as to why this happens).

:-1: error: Automatic patching failed at C:\QtSDK\Symbian\SDKs\Symbian1Qt473\bin\createpackage.pl line 357

I've installed Qt SDK 1.2.1, and when I'm building one of the example applications - Haptics Player, for Symbian S60, using Qt 4.7.3.
The example compiles successfully, but it fails on the Deploy step. This is the compiler output:
ERROR: Automatic patching failed at C:\QtSDK\Symbian\SDKs\Symbian1Qt473\bin\createpackage.pl line 357.
make[1]: *** [ok_sis] Error 2
C:\QtSDK\Symbian\SDKs\Symbian1Qt473\epoc32\tools\make.exe: *** [sis] Error 2
01:38:16: The process "C:\QtSDK\Symbian\SDKs\Symbian1Qt473\epoc32\tools\make.exe" exited with code 2.
Error while building project hapticsplayer (target: Symbian Device)
When executing build step 'Create SIS Package'
However, a newly created, empty project runs on my phone successfully, i.e. this error happens in the Example project that ships with Qt SDK, but not for a newly created project.
How do I fix this error?
Upon closer inspection of the compiler output, I noticed this:
Patching: Executable with capabilities incompatible with self-signing detected: "hapticsplayer_patched_caps.exe". (Incompatible capabilities: "ReadDeviceData", "WriteDeviceData".) Reducing capabilities is only supported for libraries.
Patching: Unable to patch the package for self-singing.
Use a proper developer certificate for signing this package.
Apparently, the capabilities WriteDeviceData and ReadDeviceData can't be used for self-signed packages, and require a proper developer's certificate (which is not free, and I don't have it).
Removing those lines from the .pro file fixed the problem, and Haptics Player now compiles:
symbian: {
TARGET.CAPABILITY = WriteDeviceData ReadDeviceData
}
It seems it does not really need those capabilities, I have no idea why they were added. Probably an oversight.