I am working on project that is uses abp (asp net boilerplate) v 6.3.0 and dotnet core v5 with reactjs client.
After run its server with dotnet run, I see some logs on the terminal that is show the background jobs are working and this messages are saving in the logs.txt file.
after some moment the logs.txt file was very huge and find some especial error in it is very hard.
could you help me to disable log the background job worker?
vs code terminal after dotnet run in host
logs.txt file
I was suffering the same issue here, and found a way to do this through log4net (not abp). The trick I used is prevent logging from specific loggers (the ones that keep logging every 5 seconds). Here is the log4net config file, with the added filters
log4net config with
Related
I am developing a simple console application with .NET Core 2.
Its purpose is to clean up a Database once per day.
This means the application does never stop after once started.
This application is part of Solution where also a .NET Core Rest API lives, to access the same database so its also part of the same Gitlab repository.
Now i want to publish and start the console app via the existing Continuous Integration pipelines of the repo. (CI pipeline is working perfectly for the REST Api project)
Building, testing and publishing works perfectly, the only problem is running the console application.
I tried a few attempts by now, the outcome is always, that the pipeline gets stuck after the application startet. I guess it is like that because it waits till the app finishes, what never happens.
I tried by now:
starting the app directly in the gitlab_ci.yml
gitlab_ci.yml:
-cd C:\publishFolder
-DB_Cleaner.exe
-> The application is executed directly in the Runner console
gitlab_ci.yml:
-cd C:\publishFolder
-start cmd.exe /k DB_Cleaner.exe
-> The runner is stuck till it got canceled by timeout
Running a bash or powershell script to run the application
gitlab_ci.yml:
-cd C:\ScriptFolder
-runDBCleaner.cmd
runDBCleaner.cmd:
-cd C:\publishFolder
-start cmd.exe /k DB_Cleaner.exe
-> The runner is stuck till it got canceled by timeout
Runner is running on a Win-64 virtual machine.
Is there a way to start the application to run Independent from the gitlab-CI-Runner?
See This Forum. It is working for me using this script:
- 'powershell.exe D:\app\CiTest.exe'
The CiTest.exe is a .Net 4.8 console app.
I am using Visual Studio 2017 version 15.8.7 on windows 10.
This issue is happening for Asp.net MVC 4 websites and Web Api 2. Not for Aspnet.Core sites (so far)
Lately I have been having issues where I will be debugging a website and it will work fine then all of a sudden the next time you start the project up, it gives a 404 error. The only way to fix the error is to use a different computer, create a new project and copy the info over.
Every time I start the debugger and get 404, this event is recorded.
The directory specified for caching compressed content
C:\inetpub\temp\IIS Temporary Compressed Files\Clr4IntegratedAppPool
is invalid. Static compression is being disabled.
Things I have tried.
Uninstal VS / IISExpress and reinstall, including delete all folders in program files
Create a new project and copy code over. (works, but then happens again later on)
Use different computer. (works, but eventually that computer hits the issue too)
Tried creating the temporary folder and giving "Everyone" full control of it.
Tried changing port number and re-creating virtual directory
Tried deleting entire solution folder and re-cloning repo.
The issue does not happen on the web servers, only locally.
Any idea on what is going on? I can't find any configuration that is telling IIS to compress the files, so not sure why I keep seeing that error.
Edit
I determined that the application_start even in global.asax is never firing (StreamWriter code in it to log to a file in case debugger issue). So I assume the 404 is because the routes never get registered.
I tried updating Microsoft.AspNet.Mvc to the latest 5.2.6.
Edit 2
So I found a workaround. I installed IIS locally and publish to a folder and debug by attaching to the process. If I point IIS directly at the project or use IIS within VS it doesnt work.
I think the issue is related to some dll goofiness, project seems to work once published.
Edit 3
Found the root of the problem. I use Ubuntu/bash on windows. Cloning the git repo through bash seems to be setting the permissions wrong. If I clone through command line, the issue does not happen. Now I need to figure out why bash is screwing up the file permissions.
Same issue with VS2017 on Windows 10, default IIS Express and git for Windows. Suddenly iisexpress returns 404 on /Default.aspx!!??
Solution:
Close VS2017
Delete the git repository in the file system.
Open VS2017
Clone the git repo
this helped on my machine.
When I add Microsoft.AspNet.Identity.Samples -Version 2.2.0-alpha1 to my MVC 5.0/Web API project the Web APi stops responding.
What is the reason to this strange behavior?
Is there any workaround?
After some researches I realized that Microsoft.AspNet.Identity.Samples packages modifies the configuration process that happens in configuration phase in the beginning of Application life cycle.
So adding
GlobalConfiguration.Configure(WebApiConfig.Register) again in Configuration phase of Application life cycle should fix that problem.
I was successfully able to get DNX-Watch command using ASP.NET 5 beta 8. Its great feature though my requirement is little bit more.
I have two projects ASP.NET 5 Web API project, normal Static HTML web app(like mini SPA).
What I would not achieve is running DNX-Watch command for both projects. Only one project can run at "localhost:5000" but if I want to run other project. An error is thrown "localhost:5000" already running.
What to know if DNX-watch runs against only project?
Running multiple apps on the same port is not a dnx-watch issue. You'll get the same error if you try to start the two apps by hand too. You have to a different port for each application
Currently dnx-watch supports only one startup project per watcher instance. However, you can start multiple instances of dnx-watch and you can achieve the same result. I don't think we'll add multiple startup projects support because it creates some strange complications around console input/output and environment setup.
I've deployed the jboss-as-helloworld-errai application in my standalone jboss7.1 instance, and I deleted it later ( in the */standalone/deployments folder). But every time I restart my server it redeploys that application.
Is there another place where jboss reads the application to deploy?
Best regard
Did you delete the file while the server was running?
Probably, JBoss still finds a deployment information in one your /standalone/configuration/standalone*.xml files (at the end of the file). JBoss unpacks its deployments in one of the /standalone/tmp/vfs/temp* folders. As long as it finds a deployment in your configuration file, it will start the application.
The deployment binaries are located under the standalone/data/content. These would also need to be deleted. The best solution is to properly undeploy the application via CLI, the maven plug-in or the web console.
This does not sound like expected behaviour. Can you please confirm the steps that you are taking when using the deployment folder? For example:
Deploy
Copy application file to /standalone/deployments folder
Deployment Scanner creates a .dodeploy marker file
Deployment Scanner picks up application and creates a .deployed marker file
Application confirmed as deployed (checking the Management Console to confirm)
Undeploy
Application deleted from /standalone/deployments folder
Delete application (or) delete .deployed marker file
Deployment scanner undeploys the application and creates .undeployed marker file
Confirm application removed in console
Restart server
Confirmed removal is persistent
The README.txt file in the deployments folder shows the simple undeployment workflow in one easy step in the command line.
rm $AS/standalone/deployments/example.war.deployed
Documentation
You can read more about the deployment scanner in the official docs. There's a topic about the scanner marker files, as well as a parent topic about the scanner and deployments in general. If you are finding issues with the scanner, it's a bug. You might like to test the expected behaviour, and also try the Management Console.
Red Hat Docs - Reference for Deployment Scanner Marker Files
Red Hat Docs - About Application Deployment
Potential Issues
Don't confuse the Deployment Scanner subsystem (which watches the Deployments folder for the Standalone server instance) with the Management Console or Management CLI deployments process. You might be better off using one of the Management tools instead of the hot deployment capability to allow for more control over the state and presence of your application.