After running application in Anypoint Studio 7.12 in has been terminated after approximately 12 hours without any error code.
What is reason and how this behavior could be changed or any workarounds?
It is expected behavior. Anypoint Studio is an IDE, for development. It is not meant to execute applications for extended periods of time. If you need to execute an application for more than one or two hours use a standalone Mule runtime installation or some other deployment target like CloudHub or Runtime Fabric.
There could be plenty of reasons may not be able to tell exactly it depending on your system JVM ect.
But it's not expected behavior definitely.
Related
This error just started occurring on a few developers' systems across several packages, but I can't track down a specific cause or update. We have SSIS processes created across various targets (SQL 2012 and up), but when I open them in Visual Studio 2019 this error occurs:
Error loading XXXXXXX.dtsx: There was an exception while loading Script Task from XML: System.Exception: The Script Task "ST_36ae893a14204fac97ce8ce3b4ce8ebb" uses version 16.0 script that is not supported in this release of Integration Services. To run the package, use the Script Task to create a new VSTA script. In most cases, scripts are converted automatically to use a supported version, when you open a SQL Server Integration Services package in %SQL_PRODUCT_SHORT_NAME% Integration Services.
at Microsoft.SqlServer.Dts.Tasks.ScriptTask.ScriptTask.LoadFromXML(XmlElement elemProj, IDTSInfoEvents events)
I can open the script task, but it's as if it's new, none of the existing code is there. Some of the older packages I can open in like Visual Studio 2017 and they work, but in Visual Studio 2019 not so much. Even some packages built in Visual Studio 2019 are doing this. Here's my dev environment:
Microsoft Visual Studio Enterprise 2019
Version 16.11.17
VisualStudio.16.Release/16.11.17+32630.194
Microsoft .NET Framework
Version 4.8.04084
SQL Server Data Tools 16.0.62205.05200
Microsoft SQL Server Data Tools
SQL Server Integration Services 16.0.948.0
Microsoft SQL Server Integration Services Designer
I've tried changing the Target server to different versions, but it seems once the issue occurs it resets the script task removing all code. I'm really confused.
Any thoughts? Thanks.
Not sure if this is a good answer, but it does seem to fix the issue. I'm using SQL Server Integration Services 16.0.948.0 (v4.3), but if I go back down to 15.0.2000.180 (v3.16) the issue seems to go away. So, it's something with version 4.0 and up. Not ideal to go backwards as we're losing some of the updates - but it gets me going again. If anyone has other suggestions, please let me know.
At my company we use Visual Studio Online for source control and have an onsite build server running TFS 2013 Update 5 that we use for builds and integration tests. We have an integration build scheduled to run at midnight Sunday through Thursday. On random nights, the build will fail with the following error message:
Please contact your administrator. There was an error contacting the server.
Technical information (for administrator):
HTTP code 302: Found
This message shows up for nearly every source file in the solution.
However, we have never experienced this error when running the build manually during the day.
Can anyone provide any insight as to what might be going on and how I can resolve it?
Visual Studio service may be maintained from time to time. Check Visual Studio Online Service status first when the error occur from this website: https://www.visualstudio.com/en-us/support/support-overview-vs.aspx.
We are getting a application failed to initialize error 0xc000007b. I looked around it seems to maybe be the .NET framework, I also read a possible virus.
Our application is Visual Basic .NET 2010, running on Windows XP, Windows Update is turned on.
What fixes the problem, seems to be temporary, is take my backup copy of the .exe and replace the .exe on the machine, it runs for a few hours. Keep in mind I am 12 hours away or more from the machine, I remote to it using TeamViewer.
Will event viewer or something else give me a better idea of what happened? or more information about the error and it's cause?
I'm far from a Visual Basic guru, so I'm very puzzled as to why this application is throwing this error after running for approximately 2 years.
Can windows update cause this? Does .NET framework update itself automatically?
Thanks for any help.
Well if your program was not recompiled, I'd doubt it's the program itself, but if you have the source code you can try running it through the debugger to see what's going on, and where. Personally I'd try just reimaging your xp system and seeing if that fixes the issue.
Also, isn't xp out of support? I suppose windows updates could affect it. I've seen updates cause older applications to break, so it is a possibility. You can look at the recent updates and roll them back.
I just created a new empty universal app (windows 10) and checked it in on my visual studio online project.
The configured build is constantly failing on following error...
The imported project "C:\Program Files
(x86)\MSBuild\Microsoft\WindowsXaml\v14.0\8.2\Microsoft.Windows.UI.Xaml.CSharp.targets"
was not found. Confirm that the path in the declaration is
correct, and that the file exists on disk.
I set build configurations to use VS2015 but without any luck.
I keep thinking there's a simple configuration I'm missing here... but can it also be that it's not yet supported?
The project itself is just the standard template from Visual Studio.
I'm having a similar issue running with MSBuild 8.2 target missing under VS2013 Update 5 under Windows 10 TH1. Except my target is Microsoft.Windows.UI.Xaml.Cpp.targets. So not necessarily an issue with Visual Studio but rather the substitution for $(TargetPlatformVersion) in the targets definition:
<Import Project="$(TargetPlatformVersion)\Microsoft.Windows.UI.Xaml.Cpp.targets" />
I'm building a project from Microsoft (https://github.com/Microsoft/winsdkfb), so I don't think this is your problem (meaning you've not done anything incorrect).
I know this isn't an answer, but I suspect we're caught in a gap in the Windows 10 SDK & Tools. Those aren't scheduled to be complete and available until 29 July even though VS2015 has RTM'd. I tried to track down something in the VS2015 release notes without luck.
Just inform the solution I found on this thread.
At the time of writing, it appeared that VSTO serves were not yet updated with
the Windows 10 SDK.
The only way back then to make it run was by creating your own Build VM (through Windows Azure) and link it to your VSTO builds.
I posted the thread and got the answer on the MSDN TFS forum.
I have not tried it right now, but since Windows 10 is officially released now, I guess it may work out of the box.
We now support building Universal Windows Platform (UWP) projects on the hosted build service.
I would like to run a .exe file made with visual studio 2003 but I get an error every time I run it on a windows 7 machine, vista machine, and xp machine. The error on Windows 7 and vista says "application has stopped working" and then makes me close the error box.
In windows xp it's a little different error, "the application failed to operate (0xc0000135) Click on OK to terminate the application."
That error code seems to indicate the application failed to initialize correctly.
It is possible that the anticipated .NET version is not present.
As far as I know, VS 2003 by default compiles against the .NET 1.1 library. There is no straightforward way of installing this on a Windows 7 or Vista box. Do you need to compile it against the .NET 1.1 library, or can you load it in VS2005, change the output .net version to 2.0 or higher, and recompile the application?
If you have the source code to the application, try running the application in debug mode and stepping through line by line until you find the exception. If you do not have the source code, possibly try running the application in a couple different compatibility modes. Another option to try is to check the windows event log for anything more specific.
If you want to get really deep into it, you can use SysInternals ProcMon.exe and filter on the failing exe to view the WinAPI calls that are happening during the failure.
Also, a basic search of forums shows that error is usually accompanied with framework issues. Either recompile the application or check out what your required framework is in the VS2003 project settings.