I've googled for the answer for some time, but I didn't find it.
I work with IBM DB2 and I have a set of sql-scripts. These scripts contains some test data, and I need this data to be loaded into my database. To load it, I need to call DB2CW.BAT, because I can't load it just using cmd. I need to load test data automatically, for this I have build.xml file which contains:
<target name="target-name">
<exec dir=".." executable="cmd.exe" failonerror="true">
<arg line="/c DB2CMDADMIN.exe DB2CW.BAT data.cmd source dbname user pass"/>
</exec>
</target>
There:
data.cmd - script that just loads test data into db
source - where sql-scripts with data are located
So, what's going wrong? When I run this ant-target, I catch UAC window (user account control). It asks me what to do - allow access or not for IBM DB2 to do smth. It's not a problem to just click 'Yes', but I need this data to be loaded automatically. I do not monitor the process, I just need a result. That's a problem.
I've solved it just by switching UAC off, but this solution is unacceptable for the customer. Any ideas of how to avoid this problem?
I use Windows 7 Enterprise.
Have you tried Run as Administrator?
Related
I have successfully packaged a Delphi app in an MSIX container, but I've run into a problem with one of my app's requirements: Upon updating the app from the Store, its background process (a console exe) is shut down (of course) and replaced with a new copy that is designated in AppxManifest.xml to run when the main app is first opened:
<Extensions>
<desktop:Extension Category="windows.startupTask" Executable="CwHelper.exe" EntryPoint="Windows.FullTrustApplication">
<desktop:StartupTask TaskId="CwHelper" Enabled="true" DisplayName="Capture Manager" />
</desktop:Extension>
</Extensions>
This all works fine, but it means that the background exe is left not running until the main app is opened subsequent to the update. This is highly undesirable.
My Internet spelunking of the MSFT docs leads me to think that I should be able to automatically restart the background app by inserting into the above <Extensions>...</Extensions> block a second Extension something like this:
<Extension Category="windows.updateTask" Executable="<some>.exe" EntryPoint="<some entrypoint>" >
</Extension>
So far, I have not been able to discover what should be my (Delphi-created) <some>.exe and its EntryPoint. Indeed, I have not found any example of this specific use of that Extension Category. Can it actually be used in this way by a desktop-bridge app? If so, can anyone give me pointers as to what I should put into those blanks?
Note added: I've tried repeating the exe's name and Windows.FullTrustApplication in the updateTask definition fields and that actually passed Certification, but it generates a fatal downloading error when the Store tries to install it.
Another note added: #StefanWick kindly pointed out that he has published an example of the very thing I need here using MSFT's toolset. Unfortunately, it is not clear to me how to translate his C# and Visual Studio labels into a Delphi app. Any advice on that would be greatly appreciated.
Answering my own question after about a month's research, I found out that the answer for now is "no" because the necessary IBackgroundTasks interface is not (yet?) available to Delphi according to Embarcadero Customer Support.
But the good news is that this is probably not needed because the "right" way to restart an app after a Store update is described in MSFT docs here.
I face the following problem: whenever i try to start Jetty with an application instance i need check if the application is running. I need to do that from an ant target.
I want to have something behaving like the following pseudocode:
**
<target name="target1"
depends="run-jetty-with-application"
description="Target1">
<--when run-jetty-with-application is ok(jetty is up and application is running)-->
<antcall target="target2"/>
<--end when-->
</target>
**
I should also mention that i have no publicly exposed urls that could give me the status of the application.
I'm not after the hacky solution like waitfor.
Thanks in advance!
There are only 2 ways to know if Jetty is started, all webapps are deployed without error, all lifecycle is started successfully, and the server is available to serve content.
Periodically ask for a resource on that web app, confirming that it is up and running. (timeout with failure if resources doesn't make itself available after a period of time)
Hook into the LifeCycle.Listener on the Server component, wait for the .lifeCycleStarted(LifeCycle event) for the server, then walk the entire handler tree, looking for any Handler component that failed to deploy via the DeploymentManager.
As you can imagine, the first technique is the easiest.
This is the <waitfor> facility in Ant, and is what the Jetty project itself uses.
The second approach requires a custom Ant task.
You can either write it yourself, and know that it will do what you want. Or use the jetty-ant tasks with daemon mode to get almost the same thing (the JettyRunTask in daemon mode starts up the server, but it does not wait for start to finish or the webapps to deploy successfully before it returns control to ant).
I'm trying to run QA-C 7.2 on a Nightly Build that I program using Python.
It does run but the problem I encounter is, that I cannot save the license file configuration settings because IM not a 'license admin'. Hence, everytime I run QA-C it requires me to browse to the license.dat
Does anyone know a way around this, for example passing the license file configuration (eg path2license_dat) as a parameter when I call the exe? Or somehow saving this information?
I found out that it works when setting the environment variable LM_LICENSE_FILE to the path to license.dat
I'm trying to configure a Topshelf-based Windows service to log to a custom event log using Topshelf.Log4Net and log4net. This works fine if I run the application in command-line mode. When I try to install the service with BillsTestService.exe install, I get:
INFO Topshelf v3.1.107.0, .NET Framework v4.0.30319.18052
DEBUG Attempting to install 'BillsTestService'
Running a transacted installation.
...
Service BillsTestService has been successfully installed.
Creating EventLog source BillsTestService in log Application...
An exception occurred during the Install phase.
System.ArgumentException: Source BillsTestService already exists on the local computer.
...
at System.Diagnostics.EventLog.CreateEventSource(EventSourceCreationData sourceData)
I've tried running EventLog.DeleteEventSource("BillsTestService"); in LINQPad before installing; that succeeds, but a subsequent service install still fails.
My log4net appender configuration is:
<appender name="ErrorEventLogAppender" type="log4net.Appender.EventLogAppender" >
<threshold value="ERROR" />
<logName value="MyCompanyServices" />
<applicationName value="BillsTestService" />
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%-5level %logger - %message%newline" />
</layout>
</appender>
What am I doing wrong?
The intent is to have multiple services log errors to the same log name (with different application names); the log would be created by Operations.
Part of the issue is that Topshelf automatically creates an eventlog source named after the service when you install. Since the log4net appender applicationName is also used as an eventlog source, that cannot be the actual application/service name. The source must be unique on the local computer. I added a "Source" suffix to the name in the log4net configuration.
The other part is that the service does not have rights to create the log. It can create a new source, but not a new log. One way to do this is in code (I used LINQPad):
EventLog.CreateEventSource("FOODEBUG", "MyCoSvc");
EventLog mylog = new EventLog("MyCoSvc");
mylog.Source = "FOODEBUG";
mylog.WriteEntry("This is a test.");
EventLog.DeleteEventSource("FOODEBUG");
I'm not positive if you actually have to write to the log to create it; after spending over two days on this, I'd rather be safe.
Also note that log names are limited to 8 characters; you can go longer, but the system only considers the first 8 characters as significant.
There's no need to move the log4net initialization as Chris Patterson suggested. Simply including
configurator.DependsOnEventLog();
configurator.UseLog4Net("MyService.exe.config");
in the HostFactory.Run delegate is sufficient. (I'm using Topshelf.Log4Net.)
Finally, I'm reasonably sure that the entire Windows event logging system is flaky. Event Viewer's refresh doesn't work in all cases, at one point my Application log entries disappeared, and I believe I've seen different results after a reboot.
Move your log4net initialization to the ConstructUsing() configuration delegate for the service instead of specifying for use during install/uninstall which doesn't require the service class to be instantiated.
Or, only use the event log appender when the actual service is running, by either adding the appender outside of the config file or modifying the configuration to eliminate the event log appender unless an ERROR or FATAL event occurs.
My guess is the DEBUG/INFO level events are trying to log to the appender, and the source does not exist yet.
I just started using VS 2010 to create a Cloud Service (HealthTracker), and I attached a MVC2 web project to it. When I hit Debug, the dev fabric was started and I was able to navigate my web app on my machine as expected.
I decided MVCWebRole2 was a bad name for my web app, so I renamed it to HealthTrackerMVC. I used Refactor --> Rename to change MVCWebRole2 to HealthTrackerMVC. I Built clean and now when I hit debug the dev fabric starts, and the web app never starts and eventually it exits debug mode without me doing anything.
How do I fix this? I'd rather not start over with everything...
UPDATE
I have checked the ServiceConfiguration.cscfg, the ServiceDefinition.csdef and the solution file. All the names match, and all the GUIDs match. I even renamed the folder that housed HealthTrackerMVC (formerly named MVCWebRole2) and edited the solution file to point to the new project. Everything loads and builds correctly. The Development Fabric shows HealthTrackerMVC starting, says it's busy, then shuts it down, rather quickly. See the attached screenshot:
So I know my web role is being started... why is it shutting down so quickly?
Check the Azure configuration files, as both reference the role name and I don't belive VS's refactor command hits. If your project is building and the role simply isn't launching, its most likely as a result of the role not knowing what to start.
In ServiceDefinition.csdef
<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="YourAzureService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
<WebRole name="HealthTrackerMVC" vmsize="Small" enableNativeCodeExecution="true">
...
In ServiceConfiguration.cscfg
<?xml version="1.0"?>
<ServiceConfiguration serviceName="YourAzureService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration">
<Role name="HealthTrackerMVC">
...
If that doesn't work, right click on "Roles" under the Cloud Service Project in Solution Explorer. The ADD menu should have an option for "Web Role Project in Solution". Select that and link up your new role. Delete the old role as well at this point
If that still doesn't work, go to the file system where the project is stored and open the .ccproj file (Cloud Service Project) in a text editor.
Look for the reference to the previous role (ccproj are in MSBUILD format). It will be something like:
<ItemGroup>
<ProjectReference Include="Folder\MVCWebRole2.csproj">
<Name>YourAzureService</Name>
<Project>{26f72b59-1423-4175-b401-9c8f5f45db2a}</Project>
<Private>True</Private>
<RoleType>Web</RoleType>
<RoleName>MVCWebRole2</RoleName>
</ProjectReference>
</ItemGroup>
Change references to the new HealthTrackerMVC project (name and .csproj ref) and you should be good to go. Most likely the project GUID hasn't changed, but if somehow it did, just open up the SLN file to get that number.
Once you change on this VS should prompt to reload the Solution/Projects. If not, you should reload anyways.
I recommend to check Web.config and the actual start-up logic (i.e. Azure fabric is known to silently kill web projects with invalid web config without raising any errors; that's something that just made my life exciting a few times).
Just some ideas. For example you can try by starting web project alone (just like a usual project). If it works - drop an existing web role and add a new one to the solution (referencing this web project) and try running it in the dev fabric. If it does not, but web project runs alone - export it to a fresh solution and add to a new web role there.
This is a bit of a long shot, but if you have overwritten the RoleEntryPoint and overwritten the Run method, it should contain something like
public override void Run()
{
while (true)
{
Thread.Sleep(8000);
}
}
If this method ever returns, your application will stop.