When I publish my dnx web app via dnu publish to an IIS server, it works fine with a script that looks like this
dnu publish pathToLocalSource --out \\appserver\appuat --configuration DEBUG --no-source --runtime dnx-clr-win-x64.1.0.0-beta6
It works fine that is - until someone hits the website and then I can no longer publish due to a file lock
Microsoft .NET Development Utility CLR-x64-1.0.0-beta6-12256
Executing script 'prepare' in project.json
Copying to output path \\appserver\appuat
Using Package dependency Microsoft.AspNet.Mvc 6.0.0-beta6
Adding NuGet package C:\Users\[username]\.dnx\packages\Microsoft.AspNet.Mvc\6.0.0-
beta6\Microsoft.AspNet.Mvc.6.0.0-beta6.nupkg to \\appserver\appuat\approot\packages
Installing Microsoft.AspNet.Mvc.6.0.0-beta6
System.IO.IOException: The process cannot access the file '\\appserver\appuat\approot\packages\Microsoft.AspNet.Mvc\6.0.0-b
eta6\lib\dnx451\Microsoft.AspNet.Mvc.dll' because it is being used by another pr
ocess.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, I
nt32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions o
ptions, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolea
n useLongPath, Boolean checkHost)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access,
FileShare share)
at Microsoft.Framework.PackageManager.Publish.PublishOperations.ExtractFiles(
ZipArchive archive, String targetPath, Func`2 shouldInclude)
at Microsoft.Framework.PackageManager.NuGetPackageUtils.ExtractPackage(String
targetPath, FileStream stream)
at Microsoft.Framework.PackageManager.NuGetPackageUtils.<>c__DisplayClass0_0.
<<InstallFromStream>b__0>d.MoveNext()
I can solve this by RDP'ing to the server and executing iisreset
What is the recommended way to get around this? Publish an app_offline.htm first?
app_offline.htm isn't supported by dnx at this time (issue #141) and has no effect.
Issue #141 talks about using WebDeploy to recycle the app pool. I really dislike webdeploy's fiddly setup with magic local security policy incantations and hope to avoid it.
So since this is a UAT box and I can be loose with security settings, I added this to my deploy script:
iisreset $targetMachine /restart
where the executor of the script needs to be a local admin of $targetMachine.
Related
I used installShield LE 2015 to build my application's installer and is successful. The problem am having now is that there's a Ms access db file in the installation location which i need to restore from the main application, but when i try to restore it, i get an error "Access to the path "C:\Program Files (x86)\RC record system\RecordSystemDb.accdb" is denied. Please someone should tell me how to resolve this issue.
I'm trying to update my Win 8.1 app. The designer loads just fine for the .Winsows project, but when I try to edit XAML files from the .WindowsPhone project I keep getting this error:
System.InvalidOperationException
The Windows Software Development Kit (SDK) required by the XAML Designer was not correctly installed. Consider repairing your installation of either Visual Studio or the Windows SDK.
at Microsoft.VisualStudio.DesignTools.HostUtility.Platform.AppContainerProcessDomainFactory.CreateDesignerProcess(String applicationPath, String clientPort, Uri hostUri, IDictionary environmentVariables, Int32& processId, Object& processData)
at Microsoft.VisualStudio.DesignTools.DesignerContract.Isolation.Primitives.ProcessDomainFactory.ProcessIsolationDomain..ctor(ProcessDomainFactory factory, IIsolationBoundary boundary, AppDomainSetup appDomainInfo, IIsolationTarget isolationTarget, String baseDirectory)
at Microsoft.VisualStudio.DesignTools.DesignerContract.Isolation.Primitives.ProcessDomainFactory.CreateIsolationDomain(IIsolationBoundary boundary)
at Microsoft.VisualStudio.DesignTools.HostUtility.Platform.AppContainerProcessDomainFactory.CreateIsolationDomain(IIsolationBoundary boundary)
at Microsoft.VisualStudio.DesignTools.DesignerContract.Isolation.Primitives.IsolationBoundary.Initialize()
at Microsoft.VisualStudio.DesignTools.DesignerContract.Isolation.Primitives.IsolationBoundary.CreateInstance[T](Type type)
at Microsoft.VisualStudio.DesignTools.DesignerContract.Isolation.IsolatedObjectFactory.Initialize()
at Microsoft.VisualStudio.DesignTools.DesignerHost.Services.VSIsolationService.CreateObjectFactory(IIsolationTarget isolationTarget, IObjectCatalog catalog)
at Microsoft.VisualStudio.DesignTools.DesignerContract.Isolation.IsolationService.CreateLease(IIsolationTarget isolationTarget)
at Microsoft.VisualStudio.DesignTools.DesignerContract.IsolatedDesignerService.CreateLease(IIsolationTarget isolationTarget, CancellationToken cancelToken, DesignerServiceEntry& entry, IServiceProvider serviceOverrides)
at Microsoft.VisualStudio.DesignTools.DesignerContract.IsolatedDesignerService.IsolatedDesignerView.CreateDesignerViewInfo(CancellationToken cancelToken)
at Microsoft.VisualStudio.DesignTools.DesignerContract.Isolation.IsolatedTaskScheduler.InvokeWithCulture[T](CultureInfo culture, Func`2 func, CancellationToken cancelToken)
at Microsoft.VisualStudio.DesignTools.DesignerContract.Isolation.IsolatedTaskScheduler.<>c__DisplayClass10_0`1.<StartTask>b__0()
at System.Threading.Tasks.Task`1.InnerInvoke()
at System.Threading.Tasks.Task.Execute()
I tried reinstalling the 8.1 SDK a few times, no luck. What can be causing this?
Recently faced the same problem with Visual Studio 2015 Enterprise running on Windows 10, attempted cleaning all the caches, reinstalling, manually checking the file permissions and a bit more, only fixed it by following the instructions here, which are for VS2012 but work fine for VS2015.
To make it easier for you (credits to maeneak as it's his solution):
x86, do the following for the ‘Reference Assemblies’ directory in your "Program Files"
x64, do the following for the 'Reference Assemblies' directory in both 'Program Files' and 'Program Files (x86)'
This must be done as administrator
Remember to close all instances of Visual Studio.
Select the folder in Windows Explorer, right-click and select
'Properties'
Click the 'Security' tab then click the 'Advanced...' button
At the top of the new window there should 'Name' and 'Owner'. Next
to owner click the 'Change' link.
In the new window make sure you have your local computer selected
under 'From this location:'. If not click 'Locations...' and select
your local computer, then click 'OK'.
In the textbox under 'Enter the object name to select, type 'Users', click 'Check Names...' and Click 'OK'
At the top of the page check the option 'Replace owner on
subcontainers and objects'. Click 'Apply'. You may be prompted to
shut the properties dialog to apply the ownership changes, if so
close all dialogs then repeat steps 1 and 2.
On the 'Permissions' tab select 'Users' and click 'Edit'.
Select 'Full Control' then click 'OK'.
Hope this helps you!
Running Nunit console inside a MSBuild project a command is built in order to execute the tests, that command includes about 90 paths, each one is the full path of a compiled test project (.test.dll) and contains at least 100 characters but no more than 150.
When the script run I got the following error:
NUnit version 2.5.10.11092
Copyright (C) 2002-2009 Charlie Poole.
Copyright (C) 2002-2004 James W. Newkirk, Michael C. Two, Alexei A. Vorontsov.
Copyright (C) 2000-2002 Philip Craig.
All Rights Reserved.
Runtime Environment -
OS Version: Microsoft Windows NT 6.1.7601 Service Pack 1
CLR Version: 2.0.50727.5485 ( Net 2.0 )
ProcessModel: Default DomainUsage: Multiple
Execution Runtime: Default
Unhandled Exception:
System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Builds\123\XXXX\XXX.Build.Sonar\srcDroplocation\Build\x86\Release\xxxxx.xxxx.CustomTypes.Test.dll'.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights
, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolea
n bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access)
at NUnit.Core.AssemblyReader.CalcHeaderOffsets()
at NUnit.Core.AssemblyReader..ctor(String assemblyPath)
at NUnit.Util.RuntimeFrameworkSelector.SelectRuntimeFramework(TestPackage package)
at NUnit.Util.DefaultTestRunnerFactory.GetTargetProcessModel(TestPackage package)
at NUnit.Util.DefaultTestRunnerFactory.MakeTestRunner(TestPackage package)
at NUnit.ConsoleRunner.ConsoleUi.Execute(ConsoleOptions options)
at NUnit.ConsoleRunner.Runner.Main(String[] args)
the original path of this file is 'C:\Builds\123\XXXX\XXX.Build.Sonar\src\Droplocation\Build\x86\Release\xxxxx.xxxx.CustomTypes.Test.dll'. The file exists, and I notice that in the exception there is a missing backslash in the path between src and Droplocation.
This issue happens in my build server, in my local machine works, the difference is that in my local machine the folder is not so deep : 'C:\T\XXX\Droplocation\Build\x86\Release\xxxxx.xxxx.CustomTypes.Test.dll'
Is there any restriction regarding the paths for the use of NUnit?
I also try to create a .nunit file in order to put all the references on it but it lead to another issue
Indeed it is bug in NUnit version 2.5.10.11092.
Create a drive unit pointing to C:\Builds\123\XXXX\XXX.Build.Sonar\src\Droplocation
subst t: C:\Builds\123\XXXX\XXX.Build.Sonar\src\Droplocation
change the $(OutDir) from C:\Builds\123\XXXX\XXX.Build.Sonar\src\Droplocation to t:
The missing slash in the middle of your path is caused by your build script, not NUnit. My guess is that the build script is appending two strings together, neither of which have the necessary slash. If the same build script is working on your box, it may be a global variable on the server has no begin/end slash where the variable on your machine does.
Edit: Based on your comment above, you may be running into a Windows limitation. According to this support page, the command prompt is limited to 8191 characters. This limitation is after any environment variables are expanded. You may need to reduce the number of arguments or have the build server compile to a shorter path.
I'm trying to publish a relatively new ASP.NET site to azure appservice from Visual Studio.
I'm getting the following error message during the preview:
The "Dnu" task failed unexpectedly.
System.Exception:
Microsoft .NET Development Utility Clr-x86-1.0.0-rc1-16231
Copying to output path C:\Users*****\AppData\Local\Temp\PublishTemp*****************.********.WebApi114
Error: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
at Microsoft.DNX.Tasks.Dnu.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.d__26.MoveNext()
Path is long indeed. How do I fix it?
Error is from windows file API, not control by Azure App Service. Sadly I think you will have to find a way to shorter your file path in order to fix this issue.
I was running into the same issue trying to build an Angular2 app locally. So I tend to agree with Xiaomin that it may be a local issue. What worked for me was to run the dnu publish command from a command prompt with the output flag set with a shorter folder destination provided. For example, navigate to the location of the project you want to publish in a command prompt and type:
"dnu publish --runtime active -o c:\Sample"
The above command will post your output to c:\Sample.
You can interrogate the options as follows:
"dnu -help"
"dnu publish -help"
I'm using Hudson as a continuous integration server. The jobs ultimately kick off MSBuild. Everyone once in a while, my build fails with a non-code-compilation error out of MSBuild:
C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(2703,9): error MSB3021: Unable to copy file "..\Lib\Microsoft\Microsoft.Practices.Unity.Configuration.dll" to "bin\Debug\Microsoft.Practices.Unity.Configuration.dll". Access to the path 'bin\Debug\Microsoft.Practices.Unity.Configuration.dll' is denied.
When I examine 'bin\Debug\Microsoft.Practices.Unity.Configuration.dll', I find it to be a 0-byte file.
I'm at a loss for why this file is being problematic. Any ideas?
MS Build Copy task has undocumented feature, at least Google keeps silence.
If set system wide environment variable MSBUILDALWAYSRETRY=1
This task will retry to copy a file even it gets Access Denied exception during copy operation
Example of output
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (3513): Got System.UnauthorizedAccessException: Access to the path 'C:\Builds\8\28\Binaries\Release\fr\System.Spatial.resources.dll' is denied.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite, Boolean checkHost)
at System.IO.File.Copy(String sourceFileName, String destFileName, Boolean overwrite)
at Microsoft.Build.Tasks.Copy.CopyFileWithLogging(FileState sourceFileState, FileState destinationFileState)
at Microsoft.Build.Tasks.Copy.DoCopyWithRetries(FileState sourceFileState, FileState destinationFileState, CopyFileWithState copyFile) copying C:\Builds\8\28\Sources\Main\Solutions\packages\System.Spatial.5.2.0\lib
et40\fr\System.Spatial.resources.dll to C:\Builds\8\28\Binaries\Release\fr\System.Spatial.resources.dll and HR is -2147024891
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (3513): Retrying on ERROR_ACCESS_DENIED because MSBUILDALWAYSRETRY = 1
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (3513): Could not copy "C:\Builds\8\28\Sources\Main\Solutions\packages\System.Spatial.5.2.0\lib
et40\fr\System.Spatial.resources.dll" to "C:\Builds\8\28\Binaries\Release\fr\System.Spatial.resources.dll". Beginning retry 1 in 1000ms. Access to the path 'C:\Builds\8\28\Binaries\Release\fr\System.Spatial.resources.dll' is denied.
Sounds like a process is holding bin\Debug\Microsoft.Practices.Unity.Configuration.dll open.
You can check that earlier by renaming 'bin' to something else, like 'bin-old' and then removing 'bin-old' If any process is holding the files in 'bin' open, the rename will fail.
Use Handle.exe from SysInternals (Microsoft) to see which files are being held open by which processes.
Run this at a cmd prompt when you get the error;
Handle.exe > OpenFile.txt
Notepad.exe OpenFile.txt
Then search OpenFile.txt for the file that is locked and you'll see the process.
Ryan
See also http://blogs.msdn.com/aaronhallberg/archive/2007/10/22/error-msb3021-and-team-build.aspx and MSBuild & TeamBuild - BuildInParallel failing because of MSB3021 file permission violation