We have multiple projects that are making use of the service bus library. We are currently using v2.6.5 at the moment and we've been getting several warnings for unit tests that calls to the code in the library. This is the warning message:
System.AppDomainUnloadedException: Attempted to access an unloaded AppDomain. This can happen if the test(s) started a thread but did not stop it. Make sure that all the threads started by the test(s) are stopped before completion.
And we would get it everytime we invoke this method: TopicClient.CreateFromConnectionString(connectionString, topicName)
This warning will not appear if we use the built-in Visual Studio test runner (2012/2015) and it would appear if we opt to use the MSTest runner via the .runsettings file.
It will also not appear if I update my service bus to version 3.0.0 and above but that is not possible because we were having a separate issues with them so the only option now is the stick to version 2.6.5 and try to fix those warnings.
Any idea what could be wrong? If you guys need additional information I'm happy to come up with a simple project that is able to reproduce the warning.
Related
Got this dreaded <BEA-160228> & ToolFailureException when deploying spring-boot 2.x app on weblogic 12.1.x multiple times. Solved one with some package guesswork in <wls:prefer-application-packages>, but got another again each time we add new dependencies.
I know there's some thread asking this already, but it's usually very specific to each dependencies, i need different perspective on this.
Is there a way to debug/analyze what happened inside weblogic AppMerge process?
So we could exactly pinpoint what library caused this.
I've tried enabling debug deployment options, but didn't see any clue on the logs
I'm having trouble getting IntelliJ to recognize which source files correspond to the thing I'm trying to attach a debugger to. The project in question is a Gradle project running locally, using Java 1.7. (EDIT: I'm actually also running that project from within IntelliJ, and that's also what's building it. It's a Gretty task defined in the project's build.gradle file. I'm passing
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5006
to the JVM to open the debugging port.)
I can tell that the debugger is attaching to the process correctly since I get the "Connected to the target VM" message. But breakpoints do not get the checkmark, and they aren't hit during execution. (EDIT: This is leading me to believe that the sources aren't being attached -- The debugger is attaching to a process successfully, and I have reason to believe that process is the one I want since I'm using JVM arguments on it to open the debugging port, but it appears to me that the IDE doesn't recognize what source files correspond to the running code.)
The other person who works on this code does not seem to have this issue. He's on an older version of IntelliJ. His "use module classpath" dropdown has a <whole project> option and mine does not (though it does have <no module> -- is that the same?). Unsure which version of IJ he's on specifically; I'm on Ultimate 2018.3.
I'm sure that I need to include more information than this, but due to my unfamiliarity with Gradle as a build/run tool and with how remote debugging works in general, I don't know what information I'm missing -- of course I will provide it as soon as someone asks me for it.
BIG EDIT (and probably the real answer here): I have a feeling I'm attaching to Gradle itself rather than the task. If I choose Run -> Attach to Process, the dialog shows me "45039 org.gradle.launcher.daemon.bootstrap.GradleDaemon (5006)".
This is an extension of an earlier issue I had, which I posted about here: VB.Net Method appears to be called multiple times when it actually isn't, and returns inconsistent results
At that time I had thought the issue was fully resolved, but I've since learned that there were multiple issues. I have worked out all the kinks with the code and logic, and now I've narrowed down the last remaining issue.
Builds will run perfectly fine until one legitimately fails. After that point, all the builds on that specific agent will fail, even if there were no actual errors with the subsequent builds. When they fail, I see the exact same symptoms as I did in the other thread, which I will summarize here:
A method that is only called once appears to be called multiple times as evidenced by the build messages
The build messages will show there is 1 error, but there are no errors in the logs generated by that method (The line to write the error to the log comes immediately after the line where the error is added to the result log, in the same if statement)
Restarting the build service on the build server "fixes" the problem until the next time a build legitimately fails, at which point the cycle starts again
Build server setup:
Windows Server 2008 R2
VS 2010 Premium
Build uses a custom library
There are 4 build agents, one for each environment (Dev, QA, UAT, Prod)
The build and deploy custom library is written in VB using .Net Framework 4.5, and it calls on another library that is written using .Net Framework 4.5 as well.
The build template doesn't use msbuild. It's strictly WF that's been stripped down to the bare minimum and only calls commandline programs (Like robocopy) or custom .net classes.
I have verified that if a build fails for one agent (such as Dev), then all builds using that agent will fail. When it happens, ONLY builds that run on that particular agent will fail, other agents run just fine. I have not had a chance to test yet if just restarting the agent will "fix" it, or if I have to restart the entire service.
I have tried clearing the Visual Studio cache for the user account running the builds, but that didn't help at all. I also have a GUI interface that I designed that does all the same things as the build, and uses all the same code, and I am not able to get it to repeat the behavior.
I've enabled logs on the build controller per these steps: How to enable build agent or build controller’s logs? however they were no help when this problem occurred (There were no errors logged, nothing was different in the logs for builds that were fine vs. ones that bugged out)
I'm not sure what my next troubleshooting steps should be, I know the problem isn't with my code, and I'm having no luck searching the internet via Google, MSDN, StackOverflow, or picking the brains of my peers at other organizations.
I'm wondering if this could be a bug due to running code that requires .Net Framework 4.5 in TFS 2010 build, since it only officially supports up to 4.0.
My advice would be to change the build logger to diagnostic and look at the output, there must be some rubbish being added to the environment.
You can do this with a switch like
/l:FileLogger,Microsoft.Build.Engine;logfile=c:\build.log;Verbosity=Diagnostic
you might want to take a look here
I can already debug easily using the soft debugger as a command line option (--debug --debugger-agent=transport=dt_socket,address=host:port) to mono when starting the app, but I want my program to continue if it can't find a debugger listening or better still for it to be told to connect to a specific monodevelop soft debugger later at runtime.
Looking at the Mono.Debugger.Soft API I think this could be possible, are there any examples?
I have build cocoa application in 10.4.4 using (mac10.3.9sdk xcode version:2.2.1,universal binary), but when im trying to invoke the application in 10.3.9 the application is not getting invoked.
Can you please tell me what would be the probable mistakes or reasons of its not getting invoked???or How can i trouble shoot the issue?
which version of xcode should i use in 10.3.9 so that i can debug the code, can someone please provide the corresponding link?
The runtime failure could be for any number of reasons: missing libraries or frameworks, compiled with the wrong settings etc.
Probably your first port of call should be console.app if you are trying to run this on another machine that does not have the development tools installed. It will probably give you some clues as to why the application isn't starting up.