I'm new in MSI installers, wix and wixsharp. I need to implement installer with some actions during the installation process (like call some *.exe or set up task scheduler and so on). Bu in case of any problems and exceptions I need a rollback all installed items.
How to implement a rollback using Wixsharp (Wix#) ? I found no information on the page of this porject.
I can't figure out the practical difference between custom action and before\after install event handler. What for do I need to use exactly custom action, instead of isuage of AfterInstall even handler in wix# ?
The author of wix# helped me with rollback using permissions elevations and third party referencies to assemblies (most difficult case).
Full answer is here: https://wixsharp.codeplex.com/discussions/646337
in common way rollback can be done like this:
project.AfterInstall += project_AfterInstall;
...
static void project_AfterInstall(SetupEventArgs e)
{
try
{
//do your stuff
}
catch (Exception ex)
{
e.Session.Log(ex.Message);
e.Result = ActionResult.Failure;
}
}
Related
I'm using a namedparameterjdbctemplate to have my crud in an oracle db. I have a trigger which sometimes throws a custom exception during update or delete. Is it possible to extract its message in my Spring Boot backend and pass it on to a React front? I tried try and catch in dao and it said sqlexceptions aren't thrown there
#Override
public void delete(Integer id) {
SqlParameterSource parameters = new MapSqlParameterSource().addValue("ID_SETTINGS", id);
namedParameterJdbcTemplate.update(DELETE_SQL, parameters);
}
You are probably trying to catch the wrong exception, should be a RuntimeException and you are catching a checked Exception.
If you want to return errors/stacktraces it's best to have a global exception handler controller for uncaught exceptions and you can return responses accordingly. Typically you don't want to return SQL exceptions vanilla because this could lead to security issues, although you might return stack-traces in your dev environment, but hide them in prod. Best practice though is to not return exceptions to the front-end but instead log them, and return user-friendly error messages.
I have a project that I'm working on and I wanted to double check before going through the work of coding and testing if this was even possible. What I'm attempting to do is something along the lines of:
try {
// Do stuff
try {
// Do other stuff
}
catch {
// Fail silently
}
// Do more stuff
}
catch (...) {
// Process error
}
Is it possible to have try/catch's within try/catch's? Most languages allow this but when I attempted to search the web I could not, for the life of me, find any answers.
Thanks
An SSIS script task is C# (or VB.NET). C# allows this, ergo SSIS allows this.
Having written a few SSIS Script Tasks in my time, I'd encourage you to take advantage of Raising Events in the Script Task.
Depending on your version + deployment model + invocation method, you might want to also turn on the native SSIS Logging. Project Deployment Model (in 2012+) provides native logging. Otherwise, you will need to specify the events you'd like to log as well as the logging provider(s) you'd like to use with them. This would need to be done as part of package development. Otherwise, I like a DTEXEC call with /REP EWI will ensure Errors, Warnings and Information events are logged to the console/SQL Agent.
I want to change my RavenDB "schema" and perform a Migration at startup of ASP.Net MVC web app.
Patching mechanism seems to fit the purpose, and I try to use it like:
store.DatabaseCommands.UpdateByIndex(
"Raven/DocumentsByEntityName",
new IndexQuery
{
Query = "Tag:LogEntries",
},
new ScriptedPatchRequest()
{
Script = #"
this.IsDeleted = false;
"
}
).WaitForCompletion();
The problem is, that Patch will simply throw exception if the index is stale. But I really need to be sure that Migration was performed before continue to run the app. Are there better alternatives than wrapping it in something like:
while (true)
{
try
{
RunPatch();
break;
}
catch (Exception)
{
}
}
With Entity Framework or NHibernate (FluentMigrations) it's easy to write a Migration class, assign a Version to it, and then needed Migrations will be executed automatically in proper order.
Is there a similar built-in mechanism for Raven? Or any known best-practices for that?
Here's an answer, albeit 6 years after you asked! There is the RavenMigrations project on GitHub here:
https://github.com/migrating-ravens/RavenMigrations
This is a migration framework for RavenDB, similar to those that you will find for relational databases.
I have an interesting use case where certain exception types mean "This message is no longer valid and should be ignored" but this code doesn't have any awareness of the Bus in order to call Bus.DoNotContinueDispatchingCurrentMessageToHandlers().
I loathe boilerplate code like try/catch blocks that need to be present in every single message handler. So I started implementing a UnitOfWork to handle and swallow the exception, but I can't find a way to tell the framework that "Yes, this code generated an exception, but forget about that and just complete the transaction."
Bus.DoNotContinueDispatchingCurrentMessageToHandlers() does not work. I tried having an ITransport injected and calling AbortHandlingCurrentMessage() but that caused the entire universe to blow up. Even stepping through the source code I seem to be at a loss.
Note that it very well may be that this is a horrible idea, because faking that there is no exception when there is in fact an exceptional case would cause the transaction to commit, causing who knows how many bad unknown side effects. So it would be preferable to have a method that still rolls back the transaction but discards the message. But I would be interested in a potential "Yes I know what I'm doing, commit the transaction regardless of the exception" option as well.
As of NServiceBus version 4.4 you can control this by injecting a behavior into our handler pipeline.
This let's you control which exceptions to mute.
class MyExceptionFilteringBehavior : IBehavior<HandlerInvocationContext>
{
public void Invoke(HandlerInvocationContext context, Action next)
{
try
{
//invoke the handler/rest of the pipeline
next();
}
//catch specific exceptions or
catch (Exception ex)
{
//modify this to your liking
if (ex.Message == "Lets filter on this text")
return;
throw;
}
}
There are several samples of how this works:
http://docs.particular.net/samples/pipeline/
That said I totally agree with Ramon that this trick should only be used if you can't change to design to avoid this.
A dirty solution would be having a unit of work test the exception, put the message id in a shared 'ignore' bag (concurrent dictionary in memory, db, what works for you) , let it fail so that everything is rolled back, in the retry have a generic message handler compare the message ID and let that call Bus.DoNotContinueDispatchingCurrentMessageToHandlers()
If you do not want to work with a unit of work then you could try to use the AppDomain.FirstChanceException.
I wouldn't advice any of these as good solution :-)
Why would you like to 'swallow' unhandled exceptions?
If you want to ignore an exception then you should catch these in the handler and then just return and log this.
What I'm more interested in is what about state? You maybe have already writen to a store. Shouldn't these writes be rolled back? If you swallow an exception the transaction commits.
It seems to me you are running in a kind of 'at least once delivery' environment. THen you need to store some kind of message id somewhere.
Or is it an action initiated by several actors based on a stale state? In that case you need to have first/last write wins construction that just ignores a command based on a stale item.
If you handl an event then swallowing a exception seems not correct. They usually say that you can ignore commands but that you always have to handle events.
Shouldn't this be part of validation? If you validate a command then you can decide to ignore it.
I need to install my windows service, and have at least one instance of it. The user decides how many services they will have. But which approach will I take?
Try to make my ServiceInstall foreach the number of windows services or install them with an customization via installutil?
and then I have to solve so it does not install duplicates. But I can make an xml file that contains the service names to be installed, and read from there.
But I have read that people don't like using foreach in wix because it complicates stuff much more, and some people say installutil isn't good either. But since I don't know how many services it will be I have to solve it something like this.
And with installutil i won't get rollback either?
Does anyone know another approach?
You can run custom action which patches your MSI including service elements to install. This approach allows you to read service names from wherever you want and install as many services as you need.
Though it would be quite non-trivial for those who read your installer source code later. And to be honest I've never used this approach. But it should work...
I ended up doing this
public static void Main(string[] args)
{
if (System.Environment.UserInteractive)
{
string parameter = string.Concat(args);
switch (parameter)
{
case "install":
ManagedInstallerClass.InstallHelper(new string[] { Assembly.GetExecutingAssembly().Location });
break;
case "uninstall":
ManagedInstallerClass.InstallHelper(new string[] { "/u", Assembly.GetExecutingAssembly().Location });
break;
}
}
else
{
ServiceBase.Run(new WindowsService());
}
}
}
making my service installable and uninstallable on its own and then made customactions to install and uninstall them