Since the latest version (2022.4.0.5575) I get an obsolete warning on the HtmlHeaderFooter class in IronPdf:
CS0618: Class 'IronPdf.HtmlHeaderFooter' is obsolete: 'Please use the newer API class IronPdf.HtmlHeaderFooter'
using IronPdf;
namespace MyNamespace
{
public class IronPdfHelper
{
public void SomeMethod()
{
var x = new HtmlHeaderFooter(); // CS0618 warning here
}
}
}
As far as I can tell, I am using the correct class. There is no other HtmlHeaderFooter class. Does this mean that the obsolete message is wrong (a bug)?
Yes, it's a bug - a false deprecated message in IronPdf 2022.4.5575
It has been resolved in the newest release IronPdf 2022.5.5596, released 2022-05-02
Related
Since upgrading to TypeScript 1.6, I've been getting what appears to be a spurious error with all my ng.Types:
Typescript 1.6 class 'derivedClass' cannot extend class 'baseClass':
types of property $timeout of types base class and derived class are
incompatible
Here's the code sample:
module app.Test {
class derivedClass extends baseClass {
// Notice there's nothing in the derived class
}
class baseClass {
constructor(timeout: ng.ITimeoutService, val1: string, otherVal: ng.ILogService) {
var vm = this;
vm.$timeout = timeout;
vm.someValue = val1;
vm.otherValue = otherVal;
}
$timeout: ng.ITimeoutService; // angular.ITimeoutService works
someValue: string;
otherValue: ng.ILogService;
}
}
angular.ITimeoutService works, or adding import ng= angular; in my modules also works. This didn't used to be an issue in the previous versions of Typescript.
Is it best practice to repeat the alias (eg: import ng = angular) in each module before using it, even though that's already done in the angular.d.ts?
Is it best practice to repeat the alias (eg: import ng = angular) in each module before using it, even though that's already done in the angular.d.ts
NO. The error is happening probably because you have done this.
The code you have posted works fine by default:
I want to use different folders other than Views with NancyFx. I've created a custom bootstrapper and it looks like:
using Nancy;
namespace MyBootstrapperTest
{
public class CustomBootstrapper : DefaultNancyBootstrapper
{
protected override void ConfigureConventions(Nancy.Conventions.NancyConventions nancyConventions)
{
nancyConventions.ViewLocationConventions.Add((viewName, model, context)) => string.Concat("html/", viewName));
}
}
}
But Visual Studio is telling me that the overloaded function, ViewLocationConventions.Add, has invalid arguments. Am I missing something? I'm pretty new to Nancy, using Nancy self-hosting at version 0.21.1.
You're not closing the parenthesis properly. Also it could be convenient to clear conventions first:
nancyConventions.ViewLocationConventions.Clear();
nancyConventions.ViewLocationConventions.Add((viewName, model, context) =>
string.Concat("html/", viewName));
Let's assume that you want to create editor which implements interface LeafValueEditor<int[]> something like this:
class MyEditor implements LeafValueEditor<int[]> {
#Override
public void setValue(#NotNull int[] value) {
}
#NotNull
#Override
public int[] getValue() {
return new int[0];
}
}
If you are still using GWT 2.4 than above code will fail at runtime with NPE
Generator 'com.google.gwt.editor.rebind.SimpleBeanEditorDriverGenerator' threw an exception while rebinding 'HERE IS YOUR DRIVER CLASS' java.lang.NullPointerException: null
at com.google.gwt.editor.rebind.model.EditorModel.findBeanPropertyMethods(EditorModel.java:509)
at com.google.gwt.editor.rebind.model.EditorModel.createEditorData(EditorModel.java:407)
at com.google.gwt.editor.rebind.model.EditorModel.calculateEditorData(EditorModel.java:345)
at com.google.gwt.editor.rebind.model.EditorModel.<init>(EditorModel.java:237)
In GWT 2.5 the situation is a bit better. Editor framework will just ignore editors with such array-args in your driver description. Why does GWT-team decide to ignore the problem instead of solving it at this release?
I've looked through the source code of EditorModel and it doesn't look really hard to implement JArrayType support in that case. But it's really annoying problem cause I need to write boilerplate classes for wrapping arrays or to use java collections.
In applications based on NetBeans Platform 7.2, it is possible to
replace the ModuleInstall classes with this code:
import org.openide.modules.OnStart;
import org.openide.modules.OnStop;
#OnStart
public final class Installer implements Runnable {
#Override
public void run() {
System.out.println("enable something...");
}
#OnStop
public static final class Down implements Runnable {
#Override
public void run() {
System.out.println("disable something...");
}
}
}
My problem is that, after obfuscation, the class loader does not find
the annotated classes.
In the Proguard configuration I added (as suggested here)
-keep #org.openide.modules.OnStart class *
But apparently this is not enough or it does not work.
Does anybody have a suggestion?
From I could figure out, you need to explicitly keep the annotations that you use to keep whatever specifications. So, in your case, adding
-keep enum org.openide.modules.OnStart
would allow this annotation to be used as a selector.
Proguard really ought to include a warning message if annotation selectors are not actually matching. It also doesn't really make sense to keep the annotation, especially if it's not of runtime retention.
Have you tried -keepattributes *Annotation*? It might do the trick, based on proguard usage.
I'm using nHibernate to update 2 columns in a table that has 3 encrypted triggers on it. The triggers are not owned by me and I can not make changes to them, so unfortunately I can't SET NOCOUNT ON inside of them.
Is there another way to get around the TooManyRowsAffectedException that is thrown on commit?
Update 1
So far only way I've gotten around the issue is to step around the .Save routine with
var query = session.CreateSQLQuery("update Orders set Notes = :Notes, Status = :Status where OrderId = :Order");
query.SetString("Notes", orderHeader.Notes);
query.SetString("Status", orderHeader.OrderStatus);
query.SetInt32("Order", orderHeader.OrderHeaderId);
query.ExecuteUpdate();
It feels dirty and is not easily to extend, but it doesn't crater.
We had the same problem with a 3rd party Sybase database. Fortunately, after some digging into the NHibernate code and brief discussion with the developers, it seems that there is a straightforward solution that doesn't require changes to NHibernate. The solution is given by Fabio Maulo in this thread in the NHibernate developer group.
To implement this for Sybase we created our own implementation of IBatcherFactory, inherited from NonBatchingBatcher and overrode the AddToBatch() method to remove the call to VerifyOutcomeNonBatched() on the provided IExpectation object:
public class NonVerifyingBatcherFactory : IBatcherFactory
{
public virtual IBatcher CreateBatcher(ConnectionManager connectionManager, IInterceptor interceptor)
{
return new NonBatchingBatcherWithoutVerification(connectionManager, interceptor);
}
}
public class NonBatchingBatcherWithoutVerification : NonBatchingBatcher
{
public NonBatchingBatcherWithoutVerification(ConnectionManager connectionManager, IInterceptor interceptor) : base(connectionManager, interceptor)
{}
public override void AddToBatch(IExpectation expectation)
{
IDbCommand cmd = CurrentCommand;
ExecuteNonQuery(cmd);
// Removed the following line
//expectation.VerifyOutcomeNonBatched(rowCount, cmd);
}
}
To do the same for SQL Server you would need to inherit from SqlClientBatchingBatcher, override DoExectuteBatch() and remove the call to VerifyOutcomeBatched() from the Expectations object:
public class NonBatchingBatcherWithoutVerification : SqlClientBatchingBatcher
{
public NonBatchingBatcherWithoutVerification(ConnectionManager connectionManager, IInterceptor interceptor) : base(connectionManager, interceptor)
{}
protected override void DoExecuteBatch(IDbCommand ps)
{
log.DebugFormat("Executing batch");
CheckReaders();
Prepare(currentBatch.BatchCommand);
if (Factory.Settings.SqlStatementLogger.IsDebugEnabled)
{
Factory.Settings.SqlStatementLogger.LogBatchCommand(currentBatchCommandsLog.ToString());
currentBatchCommandsLog = new StringBuilder().AppendLine("Batch commands:");
}
int rowsAffected = currentBatch.ExecuteNonQuery();
// Removed the following line
//Expectations.VerifyOutcomeBatched(totalExpectedRowsAffected, rowsAffected);
currentBatch.Dispose();
totalExpectedRowsAffected = 0;
currentBatch = new SqlClientSqlCommandSet();
}
}
Now you need to inject your new classes into NHibernate. There are at two ways to do this that I am aware of:
Provide the name of your IBatcherFactory implementation in the adonet.factory_class configuration property
Create a custom driver that implements the IEmbeddedBatcherFactoryProvider interface
Given that we already had a custom driver in our project to work around Sybase 12 ANSI string problems it was a straightforward change to implement the interface as follows:
public class DriverWithCustomBatcherFactory : SybaseAdoNet12ClientDriver, IEmbeddedBatcherFactoryProvider
{
public Type BatcherFactoryClass
{
get { return typeof(NonVerifyingBatcherFactory); }
}
//...other driver code for our project...
}
The driver can be configured by providing the driver name using the connection.driver_class configuration property. We wanted to use Fluent NHibernate and it can be done using Fluent as follows:
public class SybaseConfiguration : PersistenceConfiguration<SybaseConfiguration, SybaseConnectionStringBuilder>
{
SybaseConfiguration()
{
Driver<DriverWithCustomBatcherFactory>();
AdoNetBatchSize(1); // This is required to use our new batcher
}
/// <summary>
/// The dialect to use
/// </summary>
public static SybaseConfiguration SybaseDialect
{
get
{
return new SybaseConfiguration()
.Dialect<SybaseAdoNet12Dialect>();
}
}
}
and when creating the session factory we use this new class as follows:
var sf = Fluently.Configure()
.Database(SybaseConfiguration.SybaseDialect.ConnectionString(_connectionString))
.Mappings(m => m.FluentMappings.AddFromAssemblyOf<MyEntity>())
.BuildSessionFactory();
Finally you need to set the adonet.batch_size property to 1 to ensure that your new batcher class is used. In Fluent NHibernate this is done using the AdoNetBatchSize() method in a class that inherits from PersistenceConfiguration (see the SybaseConfiguration class constructor above for an example of this).
er... you might be able to decrypt them...
Edit: if you can't change code, decrypt, or disable then you have no code options on the SQL Server side.
However, You could try "disallow results from triggers Option" which is OK for SQL 2005 and SQL 2008 but will be removed in later versions. I don't know if it suppresses rowcount messages though.
Setting the "Disallow Results from Triggers" option to 1 worked for us (the default is 0).
Note that this option will not be available in a future releases of Microsoft SQL Server, but after it is no longer available it will behave as if it was set to 1. So setting this to 1 now fixes the problem and also give you the same behavior as will be in future releases.