Windows Forms "Deploy Task" failing with "The process cannot access the file because it is being used by another process." in .NET5 - winforms

I've just migrated my .NET 4.8 Windows Forms application to .NET 5. The process was incredibly easy. The only problem I'm having is with Deploy. I've been using Click Once deploy with my application for years but after changing it to .NET5 and recreating the deploy, I'm getting this error. I also get the same error if I use the simpler Folder (non Click Once) deploy option. I'm deploying to a server share folder (\\HYDRA\Data\SL\IceTool) which is writable (the deploy task does actually copy the application executable into the share folder - but nothing else).
The error appears in a dialogue box containing the following text:
Publish has encountered an error.
Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details.
A diagnostic log has been written to the following location:
"C:\Users\Chris\AppData\Local\Temp\tmpF29C.tmp"
The tmpF29C.tmp file contains:
17/12/2020 01:05:34
System.AggregateException: One or more errors occurred. ---> Microsoft.WebTools.Shared.Exceptions.WebToolsException: Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details.
--- End of inner exception stack trace ---
---> (Inner Exception #0) Microsoft.WebTools.Shared.Exceptions.WebToolsException: Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details. <---
Microsoft.WebTools.Shared.Exceptions.WebToolsException: Publish has encountered an error. We were unable to determine the cause of the error. Check the output log for more details.
===================
Checking the output build log shows that the solitary Ice.exe file is "being used by another process":
2>Native image obj\Release\net5.0-windows\win-x64\R2R\Ice.dll generated successfully.
2>Skipping target "_CreateR2RSymbols" because it has no outputs.
2>Though the target has declared its outputs, the output specification only references empty properties and/or empty item lists.
2>Task "NETSdkError" skipped, due to false condition; ('#(_ReadyToRunCompilationFailures)' != '') was evaluated as ('' != '').
2>Task "NETSdkInformation" skipped, due to false condition; ('$(_ReadyToRunCompilerHasWarnings)' != '') was evaluated as ('' != '').
2>Target "GeneratePublishDependencyFile" skipped, due to false condition; ('$(GenerateDependencyFile)' == 'true' and '$(_UseBuildDependencyFile)' != 'true') was evaluated as ('true' == 'true' and 'true' != 'true').
2>Target "ComputeDependencyFileCompilerOptions" skipped, due to false condition; ('$(PreserveCompilationContext)' == 'true') was evaluated as ('' == 'true').
2>Building target "GenerateSingleFileBundle" completely.
2>Input file "C:\Workspaces\Framework\Main\Source\Core\Ice\obj\Release\net5.0-windows\win-x64\apphost.exe" is newer than output file "\\HYDRA\Data\SL\IceTool\Ice.exe".
2>Task "NETSdkError" skipped, due to false condition; ('$(IncludeAllContentForSelfExtract)' == 'true' And '$(IncludeNativeLibrariesForSelfExtract)' != 'true') was evaluated as ('false' == 'true' And 'false' != 'true').
2>Using "GenerateBundle" task from assembly "C:\Program Files\dotnet\sdk\5.0.101\Sdks\Microsoft.NET.Sdk\targets\..\tools\net472/Microsoft.NET.Build.Tasks.dll".
2>The "GenerateBundle" task failed unexpectedly.
2>System.IO.IOException: The process cannot access the file '\\HYDRA\Data\SL\IceTool\Ice.exe' because it is being used by another process.
2> at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
2> 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, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
2> at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
2> at System.IO.File.OpenWrite(String path)
2> at Microsoft.NET.HostModel.Bundle.Bundler.GenerateBundle(IReadOnlyList`1 fileSpecs)
2> at Microsoft.NET.Build.Tasks.GenerateBundle.ExecuteCore()
2> at Microsoft.NET.Build.Tasks.TaskBase.Execute()
2> at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
2> at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
2>Target "_SGenCheckForOutputs" skipped, due to false condition; ('$(_SGenGenerateSerializationAssembliesConfig)' == 'On' or ('#(WebReferenceUrl)'!='' and '$(_SGenGenerateSerializationAssembliesConfig)' == 'Auto')) was evaluated as ('Auto' == 'On' or (''!='' and 'Auto' == 'Auto')).
2>Comparison path is "C:\Workspaces\Framework\Main\Source\Core\Ice".
2>Comparison path is "bin\Release\net5.0-windows\win-x64\".
2>Comparison path is "obj\Release\net5.0-windows\win-x64\".
========== Build: 1 succeeded, 0 failed, 4 up-to-date, 0 skipped ==========
========== Publish: 0 succeeded, 1 failed, 0 skipped ==========
The deploy target folder (initially empty) contains just the single Ice.exe file. The same file that is "in use".
Here is my ClickOnceProfile.pub.xml file:
<?xml version="1.0" encoding="utf-8"?>
<!--
https://go.microsoft.com/fwlink/?LinkID=208121.
-->
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<ApplicationRevision>0</ApplicationRevision>
<ApplicationVersion>3.0.0.*</ApplicationVersion>
<BootstrapperEnabled>True</BootstrapperEnabled>
<Configuration>Release</Configuration>
<GenerateManifests>True</GenerateManifests>
<Install>true</Install>
<InstallFrom>Unc</InstallFrom>
<InstallUrl>\\HYDRA\Data\SL\IceTool\</InstallUrl>
<IsRevisionIncremented>True</IsRevisionIncremented>
<IsWebBootstrapper>False</IsWebBootstrapper>
<ManifestCertificateThumbprint>(removed!)</ManifestCertificateThumbprint>
<MapFileExtensions>true</MapFileExtensions>
<OpenBrowserOnPublish>false</OpenBrowserOnPublish>
<Platform>Any CPU</Platform>
<ProductName>IceTool</ProductName>
<PublishDir>\\HYDRA\Data\SL\IceTool\</PublishDir>
<PublishUrl>\\HYDRA\Data\SL\IceTool\</PublishUrl>
<PublishProtocol>ClickOnce</PublishProtocol>
<PublishReadyToRun>True</PublishReadyToRun>
<PublishSingleFile>True</PublishSingleFile>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
<SelfContained>False</SelfContained>
<SignatureAlgorithm>sha256RSA</SignatureAlgorithm>
<SignManifests>True</SignManifests>
<TargetCulture>en-GB</TargetCulture>
<TargetFramework>net5.0-windows</TargetFramework>
<UpdateEnabled>True</UpdateEnabled>
<UpdateMode>Foreground</UpdateMode>
</PropertyGroup>
<ItemGroup>
<BootstrapperPackage Include="Microsoft.NetCore.DesktopRuntime.5.0.x64">
<Install>true</Install>
<ProductName>.NET Desktop Runtime 5.0.1 (x64)</ProductName>
</BootstrapperPackage>
</ItemGroup>
</Project>
Could this be a bug in a relatively new framework release? (Parallel task condition?) or any I doing something wrong. Thanks.

Related

Log File does not generate complete logs although execution gets completed

Please excuse me for a long post.
I am a newbie in logging implementations and I'm trying to read a log file which gets overwritten every time the build is run. The log file contains details of some workflow execution steps.
Configurations for log4j2.xml file :-
<appenders>
<File name="InfoLog" fileName="build/var/debug.log" bufferedIO="true" immediateFlush="false" append="false">
<PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss.SSS z}{UTC} ~ [%t] ~ %-5level ~ %logger{1} ~ %msg%n"/>
</File>
</appenders>
<loggers>
<Root level="Debug">
<AppenderRef ref="InfoLog"/>
</Root>
</loggers>
An example code snippet for my logger implementation :-
Note → I have api calls to other services and require those logs too
in my file, hence I used mu.KLogging library as it made it super
easy. I wasn’t able to get the logs from calls to other apis, using
java.util.logging or org.apache.log4j libraries.
import mu.KLogging
interface TestsLogger {
companion object {
val logger = KLogging().logger(" WORKFLOW STEPS ")
}
}
//In some class
logger.info { "Running ${(workflowMap.currentStep).toUpperCase()}" }
logger.error { workflowExecutionException }
Now, when I am trying to read the debug.log file (a few seconds after all steps have been executed), for some reason, not all logs are being read from the file.
TimeUnit.MILLISECONDS.sleep(5_000)
var lines: List<String> = Files.readAllLines(File("build/var/debug.log").toPath())
On diving deep into the cause of such behaviour, I found out that, when it tries to read the debug.log file, at that moment the log file does not have all the logs in it. For some reason, last few lines of the logs get appended to file at the moment, when my build gets complete. Although, the executions have already been happened for which I need information from the logs.
FYI -> I am using Gradle Build in Intellij
I am trying to understand why this strange behaviour? And how can I solve it such that logs are
generated correctly and my file reads all the logs generated till that moment ?
You have bufferedIo set to true and immediateFlush set to false. This is good for performance in long running apps that write logs frequently, but for an application that doesn't write much it means the log events will be sitting in a buffer waiting to be written. The buffers should be flushed at application shutdown, unless it is killed or has some other terminal error that doesn't allow it to terminate normally.

ORA-00600: internal error code, arguments: [pesld103_MMap: errno 1 errmsg Opetation not permitted],

Encountering the below error:
ORA-00600: internal error code, arguments: [pesld103_MMap: errno 1 errmsg Opetation not permitted],[],[],[]...
Have changed the fstab entry to:
tmpfs /dev/shm tmpfs defaults 0 0
But then too getting the same error when trying to import. Could anyone help me out in this?
Restart the database after changing fstab. Oracle support document ORA-600 [pesldl03_MMap: Errno 1 Errmsg Operation Not Permitted] (Doc ID 1625010.1) describes the steps to change the file, but does not mention restarting the database.

Starting Go server on App Engine localhost throws error

Can anyone tell me why this is happening:
$ dev_appserver.py nmg_server
INFO 2017-07-08 17:15:37,369 application_configuration.py:461] No version specified. Generated version id: 20170708t171537
WARNING 2017-07-08 17:15:37,369 application_configuration.py:166] The Managed VMs runtime is deprecated, please consider migrating your application to use the Flexible runtime. See https://cloud.google.com/appengine/docs/flexible/python/migrating for more details.
INFO 2017-07-08 17:15:37,472 devappserver2.py:116] Skipping SDK update check.
INFO 2017-07-08 17:15:37,513 api_server.py:312] Starting API server at: http://localhost:54096
INFO 2017-07-08 17:15:37,517 api_server.py:938] Applying all pending transactions and saving the datastore
INFO 2017-07-08 17:15:37,517 api_server.py:941] Saving search indexes
Traceback (most recent call last):
File "/Users/dgaedcke/gcloud_tools/google-cloud-sdk/platform/google_appengine/dev_appserver.py", line 103, in <module>
_run_file(__file__, globals())
File "/Users/dgaedcke/gcloud_tools/google-cloud-sdk/platform/google_appengine/dev_appserver.py", line 97, in _run_file
execfile(_PATHS.script_file(script_name), globals_)
File "/Users/dgaedcke/gcloud_tools/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/devappserver2.py", line 381, in <module>
main()
File "/Users/dgaedcke/gcloud_tools/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/devappserver2.py", line 369, in main
dev_server.start(options)
File "/Users/dgaedcke/gcloud_tools/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/devappserver2.py", line 196, in start
options.api_host, apiserver.port, wsgi_request_info_, options.grpc_apis)
File "/Users/dgaedcke/gcloud_tools/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/dispatcher.py", line 223, in start
_module.start()
File "/Users/dgaedcke/gcloud_tools/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/module.py", line 1647, in start
self._add_instance()
File "/Users/dgaedcke/gcloud_tools/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/module.py", line 1799, in _add_instance
expect_ready_request=True)
File "/Users/dgaedcke/gcloud_tools/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/go_runtime.py", line 189, in new_instance
self._go_application.maybe_build()):
TypeError: maybe_build() takes exactly 2 arguments (1 given)
I'm trying to run my server for testing on localhost and it keeps exiting with this error
This appears to be a bug in Cloud SDK which is affecting dev_appserver.py when using with App Engine Managed VMs. It does not seem to be affecting App Engine Standard or App Engine Flex environments.
Until Google releases a new Cloud SDK with the fix, you can modify the CLOUD_SDK_INSTALL_DIR//platform/google_appengine/google/appengine/tools/devappserver2/go_managedvm.py file locally as shown below (added both the patchable unified diff as well as before/after just for convenience).
Also consider moving to App Engine Flex since Managed VMs are deprecated and will not be supported after October 27, 2017.
Warning: The Managed VMs beta environment (applications deployed with
vm:true) is deprecated and will be decommissioned. This page is for
users who are already using the flexible environment with vm:true in
their app.yaml and want to upgrade to the latest release. If you are
updating your application from the standard environment, see the
Migrating Services from the Standard Environment to the Flexible
Environment instead.
Diff in patchable format
--- /Users/tuxdude/google-cloud-sdk-orig/platform/google_appengine/google/appengine/tools/devappserver2go_managedvm.py 2017-07-08 11:11:11.000000000 -0700
+++ /Users/tuxdude/google-cloud-sdk/platform/google_appengine/google/appengine/tools/devappserver2/go_managedvm.py 2017-07-08 11:11:11.000000000 -0700
## -152,15 +152,9 ##
logging.debug('Build succeeded:\n%s\n%s', stdout, stderr)
self._go_executable = exe_name
- def maybe_build(self, maybe_modified_since_last_build):
+ def maybe_build(self):
"""Builds an executable for the application if necessary.
- Args:
- maybe_modified_since_last_build: True if any files in the application root
- or the GOPATH have changed since the last call to maybe_build, False
- otherwise. This argument is used to decide whether a build is Required
- or not.
-
Returns:
True if compilation was successfully performed (will raise
an exception if compilation was attempted but failed).
## -173,9 +167,6 ##
self._work_dir = tempfile.mkdtemp('appengine-go-bin')
atexit.register(_rmtree, self._work_dir)
- if self._go_executable and not maybe_modified_since_last_build:
- return False
-
if self._go_executable:
logging.debug('Rebuilding Go application due to source modification')
else:
Before:
def maybe_build(self, maybe_modified_since_last_build):
"""Builds an executable for the application if necessary.
Args:
maybe_modified_since_last_build: True if any files in the application root
or the GOPATH have changed since the last call to maybe_build, False
otherwise. This argument is used to decide whether a build is Required
or not.
Returns:
True if compilation was successfully performed (will raise
an exception if compilation was attempted but failed).
False if compilation was not attempted.
Raises:
BuildError: if building the executable fails for any reason.
"""
if not self._work_dir:
self._work_dir = tempfile.mkdtemp('appengine-go-bin')
atexit.register(_rmtree, self._work_dir)
if self._go_executable and not maybe_modified_since_last_build:
return False
if self._go_executable:
logging.debug('Rebuilding Go application due to source modification')
else:
logging.debug('Building Go application')
self._build()
return True
After:
def maybe_build(self):
"""Builds an executable for the application if necessary.
Returns:
True if compilation was successfully performed (will raise
an exception if compilation was attempted but failed).
False if compilation was not attempted.
Raises:
BuildError: if building the executable fails for any reason.
"""
if not self._work_dir:
self._work_dir = tempfile.mkdtemp('appengine-go-bin')
atexit.register(_rmtree, self._work_dir)
if self._go_executable:
logging.debug('Rebuilding Go application due to source modification')
else:
logging.debug('Building Go application')
self._build()
return True

SHFileOperation: randomly raises exceptions when deleting files

I am using SHFileOperation() to delete directories from a specific path. It is done in multiple threads and the directory that's deleted is always different.
From time to time, it throws exceptions:
Exception thrown at 0x00007FF8AF5D9D2A (ntdll.dll) in del.exe:
0xC0000008: An invalid handle was specified
and this one:
Exception thrown at 0x00007FF8ACC90A36 (shell32.dll) in del.exe:
0xC0000005: Access violation reading location 0x0000000000000001.
modules:
shell32.dll 00007FF8ACBD0000-00007FF8AE0D8000
ntdll.dll 00007FF8AF530000-00007FF8AF701000
This is the code:
SHFILEOPSTRUCTW tFileOptions = { 0 };
/* Initialize the file options structure for the deletion process */
tFileOptions.pFrom = pwstrPath;
tFileOptions.wFunc = FO_DELETE;
tFileOptions.fFlags = FOF_NOCONFIRMATION | FOF_SILENT | FOF_NOERRORUI;
/* Execute the deletions with the Shell operation */
iResult = SHFileOperationW(&tFileOptions);
if (0 != iResult)
{
printf("WTF\n");
goto lbl_cleanup;
}
SHChangeNotify(SHCNE_RMDIR, SHCNF_PATHW, pwstrPath, NULL);
The pwstrPath has a double null terminator at the end.
What can be the reason for these exceptions?
EDIT
Stack trace:
from stack trace (even without pdb symbols - with it will be much more better ) visible that exception not inside windows shell itself but in third party product - dragext64.dll (this is not native windows image) wich is implement Copy Hook Handler - i advise uninstall this or disable via registry key
HKEY_CLASSES_ROOT
Directory
shellex
CopyHookHandlers
MyCopyHandler
(Default) = {MyCopyHandler CLSID GUID}
and test after this. think exceptions must go away.
also look like some another shell extensions have bugs here - search in google SHELL32_CallFileCopyHooks. for example bug TortoiseGit.dll - note here in stack trace shell32.dll!SHELL32_CallFileCopyHooks()
so all this bugs inside implementation of ICopyHook::CopyCallback method

ClearCase db_server.exe: Error: db_VISTA error -920 (errno == "Bad file descriptor")

Seeing following errors in the server db log.
db_server.exe(): Error: db_VISTA error -920 (errno == "Bad file descriptor")
db_server.exe(): Error: Cannot open database in ".vbs\db"
Any idea, seeing this error for every 20 mins. This is happening for only two vobs.
Followed below with no luck.
http://www-01.ibm.com/support/docview.wss?uid=swg21236027
http://www-01.ibm.com/support/docview.wss?rs=984&uid=swg21148639
http://www-01.ibm.com/support/docview.wss?uid=swg21133944
The About db_VISTA errors page mentions:
db_VISTA database error -920 - no lock manager is installed
db_VISTA error 2 from OpenFileMapping() of lockmgr_almd
And reference the technote "DB_Vista -920 error and Error 2 from OpenFileMapping()"
Even if this isn't exactly the same error message, check the status of your lock manager (lockmgr.exe on Windows, lockmgr on Unix), both on the client and the server.
Regarding the db_server process, you can try a stop/restart ClearCase on the server, to reset both db_server and vob_server processes.
That can be also related to almd parameters, initially found in:
/opt/rational/clearcase/config/vob/db/vob_almd_params
(for all vobs), but also found in each vobs:
/path/to/vobstorage/yourVob.vbs/db/vob_almd_params
I usually try to raise those parameters in case of 920 errors.
For instance:
-u 4000 -q 16000
That (meaning those local vob configs) would explain why you see errors in only two of your vobs.
To stop the services on Windows: "How do I determine via Windows command line whether ALBD service is running?".

Resources