I have a build step that is part of my deployment configuration. My coworker told me it had worked once in a blue moon
I kept on getting this error consistently when I ran this build step:
Deleting dirPath (qa.comedy.net\aspnet_client\system_web\4_0_30319). [15:22:22]:
[VSMSDeploy] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.\We
\Microsoft.Web.Publishing.targets(3588, 5): Web deployment task failed.((3/28/2012 3:22:22 PM) An error occurred when the request was processed on the remote computer.)
Attempt to perform an unauthorized operation on file '4_0_30319'.
It seems that it is trying to delete the folder
aspnet_client\system_web\4_0_30319 , but has no permission to.
we run this build on a virtual machine.
Any suggestions on how to resolve this?
All help is greatly appreciated.
Thanks
I had this issue deploying as site with msdeploy and teamcity. I resolved it by deleteing these folders from my website aspnet_client\system_web\4_0_30319
Yes you can delete this folder and the next deploy will work, but with the next windows update that runs the asp.net registration tool as part of it's install will add this folder back to all asp.net sites on IIS (with the incorrect permissions) - so your deployment will fail again. You can avoid this by
Giving the deploy user elevated privileges (not a great solution for
obvious reasons)
Add the folder structure to your SC so it gets
deployed instead of the deployment trying to delete it (not ideal, but easiest)
Stop automatic windows updates (not sensible)
You might be able to do
something like this
http://blog.richardszalay.com/2012/12/18/demystifying-msdeploy-skip-rules/
to ignore the folder in deployment (I've not tried this)
As MemeDeveloper mentions in their answer, one way to fix this is to simply ignore that directory. Indeed, this is the easiest fix and doesn't require adding anything to your source control repository or build output. Just add the following to your msdeploy.exe command:
-skip:Directory="aspnet_client"
I wasn’t using TeamCity but I think I also had this issue. I was trying to deploy to Discount ASP.NET using VS2010 WebDeploy. After reading what doglin and Dan posted, I found I could workaround this problem by checking the “Leave extra files on destination (do not delete)” box. That may not be an option for everyone but it worked for me.
I faced the same problem during WebDeploy in TeamCity. I end up elevating privileges for WebDeploy account under which I do WebDeploy task. So the account have enough power to delete those folder (local admin role).
Related
Steps to reproduce are very easy.
Create a Dockerfile.
My Dockerfile has many more lines, but I have trimmed them so we can focus in the source of the problem.
Said that, these two lines alone (without anything more) show the problem.
FROM microsoft/iis
SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue'; $VerbosePreference = 'Continue'; "]
Run docker build . and you get hcsshim::PrepareLayer - failed failed in Win32: Función incorrecta. (0x1).
Windows 10 Pro 1909 (but it happened too in 1903)
Docker version: 2.1.0.5
Engine: 19.03.5
Machine: 0.16.2
I have found the solution to the problem.
Reading all the https://github.com/docker/for-win/issues/3884 bug, some have found a simple solution: rename C:\windows\system32\driver\cbfsconnect2017.sys so it isn't loaded the next boot.
Disabling that driver enables me to do a docker build for the first time in windows containers in almost a year.
In my case Box Sync was the one using that driver.
EDIT: #GustavoTM have found that pCloud raises the same problem.
EDIT2: #VonC have noticed that some people in the issue in GitHub has solved it deleting this other file: C:\Windows\System32\drivers\cbfs6.sys. I haven't tried that, but i put it if it helps others.
The good thing is that I don't need to uninstall Box, but only rename that file.
This is still an issue (still open) with Win10.
Looks like uninstalling cloud storage providers with file system filters like Dropbox, Box, etc. as a workaround is an option for some users.
Deinstall cloud storage providers or virus scanners; if you identify which one is not working please share in https://github.com/docker/for-win/issues/3884
In my case was the problem similar but the file cbfs6.sys was placed somewhere in the rest of uninstalled application Jungle disk, somewhere in the folder c:\Program files\Jungle disk .... It's part of Callback File System signed by EldoS Corporation.
The folder could be rename only and not delete directly. So I could delete its immediately after the PC restart, before running the Docker. So it could be delete during the Docker service restart too.
I am attempting a migration of SP2010 to SP2013, so far what I have accomplished is below:
1) created a backup of the contentDB from SP2010 and restored it on to SP2013
2) Added all the wsp's exported from SP2010 solution store to SP2013 soltuion store.
3) When I try to deploy a solution I get a error message saying "A feature with ID 14/5c935448-ed11-4bae-bfff-ef8b307f38ac has already been installed in this farm. Use the force attribute to explicitly re-install the feature."
most of them suggest to turn on force attribute on the feature and then do the deployment in my case I do not have code for the wsp, so unable to recompile them to turn on the force attribute.
Have used the featureadmin for SP2013 it does not find any faulty feature in the farm, it doesnot list any feature with Id 5c935448-ed11-4bae-bfff-ef8b307f38ac.
Executing select fullurl, description from features join AllWebs on
(features.webid = AllWebs.id) where featureid = '5c935448-ed11-4bae-bfff-ef8b307f38ac' lists rows of data from db but I can't find the feature folder on 14/15 hive.
Stuck at the moment trying to find a way to get the solutions deployed and perform the db upgrade. Any pointers welcome.
Thanks in advance.
You can define -force with power shell command as well.
Salam Santhosh
I face this problem before , and I resolved by adding the AlwaysForceInstall="TRUE" to the feature.xml for the WSP, after that I went to the central admin and I do uninstall and re-install to the WSP, after that you can activate the feature using STSADM or powershell normally
this is an example of the feature
I'm using web deploy to deploy an MVC4 application using EF5 code first. I made a publish profile called "development" that uses web deploy for application and database using the 'Execute Code First Migrations' checkbox to run migrations on application startup. The publishing worked great for a while. At some point I added a new publish profile called "test" to deploy to another server, which uses the ftp method of deploy and no automatic migrations. This works fine too. However, when I tried to use my old "development" publish profile again, VS changes the settings automatically to the dbDacFx way ('Update database' checkbox instead of 'Execute Code First Migrations') and I can't get it back to the way it was.
There were some other changes to the project while using the 'Test' profile, but nothing that seems to me like it could cause this. Does anyone know why VS thinks my project doesn't use code first anymore?
Since asking this question, I've run into this problem several more times in multiple versions of MVC and EF (all code first though of cource). When it happens, don't save the changes to your publish profile, make sure you are on the 'debug' build configuration, clean solution and rebuild solution. And if all that fails, restart Visual Studio and try again.
So far, this has always solved the problem for me.
Here is the right answer - is solved the problem for me.
Just rename your connection string exactly as your DbContext, e.g.
public ApplicationDbContext()
: base("Vocabulary.Domain.ApplicationDbContext", throwIfV1Schema: false)
{
}
Note that name should include namespace like "Vocabulary.Domain.ApplicationDbContext".
Don't forget to update .pubxml files:
<ObjectGroup Name="Vocabulary.Domain.ApplicationDbContext" Order="1" Enabled="True">
This article describes when publish dialog has or has no the tick "Execute Code First Migrations (runs on application start)"
This happened to me in VS2013. Neither cleaning the solution, nor restarting it worked. I tried to "re-enable" migrations and it worked. Even though I got an error message that migrations have already been enabled in project, the "Execute Code First Migrations" checkbox appeared again.
Since nothing mentioned above worked.
I downloaded the publish profile from azure and it worked flawlessly the first time
I had this problem and for me it had a different cause to any I've found documented elsewhere.
My application is spread over many projects in a solution. As I use interfaces and a separate View/Presentation model to wrap calls to the database, my front web project had no direct reference to the project containing the DbContext class. Note that this posed no problem to my running the site locally. I do this so that developers in the front end web project are not tempted to bypass the Presentation layer and go more directly to the database.
Adding this reference immediately fixed the problem and now I see the 'Execute Code First Migrations' checkbox in my Publish Profile dialog.
Just to add to the mix, don't call your Connection Class DbConn didn't seem to like that.
Here is the output after the build/web.config transformation:
Copying all files to temporary location below for package/publish:
obj\Release\Package\PackageTmp.
Publishing folder /...
Site was published successfully path_goes_here
========== Build: 0 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========
========== Publish: 1 succeeded, 0 failed, 0 skipped ==========
yet when it loads the root folder, nothing is there. Going to the site gives a Server Error of
401 - unauthorized: access is denied due to invalid credentials
understandable considering nothing is in that directory, I believe. If possibly misleading.
To work around this issue, I copied and pasted the release of the deployment server to the production server. I didn't have access issues doing this so I don't believe it was preventing me from deploying due to permissions.
How do I troubleshoot this particular scenario?
I tried the following which had worked for other people, hopefully one may work for you:
Publish as release, then go back and publish as debug again.
Publish as web deploy package then go back and publish to filesystem.
Reinstalling VS2012=0 worked until an update upgraded my Publish dialog.
None worked for me though, so the workaround I came up with is to publish as web deploy package - which actually contains the files that would be in the file system folder - get the files (from the PackageTmp folder) and deploy as before.
I found that a DLL reference was missing from one of the projects but I fixed that by adding it, unused, to the start up project, which causes it to be recognised and published.
Hope this helps.
I have tried it with /A:Basic, worked for me
/A:
Specifies the type of authentication to be used. The possible values are NTLM and Basic. If the wmsvc provider setting is specified, the default authentication type is Basic; otherwise, the default authentication type is NTLM.
I am using the 7zip standalone .exe to unzip a file. I am using the Execute Process task for this. I have tested this over and over again on multiple machines and I know it works (at least in debug mode/visual studio). I have uploaded this package the server. I have created a job that calls said package from the Package Store. The package is not able to find the .exe no matter where I put it.
My first thought was to put the .exe on the C:\ drive, which failed. I have also failed in my attempts to place the .exe on a network location that the account the package is running under has full control over.
Basically, has anybody else had issues getting the Execute Process Task to find an executable when the package is uploaded to the server?
The error message is
Can't find 7za.exe in directory C:\7zip
I'll risk a downvote for being wrong, but I believe you have a permission issue.
You say it runs fine on other servers from BIDS, try it without BIDS. Call it from a command-line on a box that it works on.
dtexec.exe /file C:\HereComesTheUnzipper.dtsx
If that works, then repeat the step on the troublesome server. RDC into the box and try again
dtexec.exe /ser localhost /sq HereComesTheUnzipper
If that still works, then you are looking at an issue with the job. What account is the SQL Agent service running as? Is the SSIS job step running as a particular set of credentials? If so, is it a SQL Server login (which wouldn't map to anything on the physical box)? Regardless of what your answer is, the resolution will be to ensure the account has access to
7z.exe
whatever scratch area 7zip may use while unpacking files (I assume %temp%)
the output folder (C:\bin\7z.exe -e e:\data\MyThing.7z)