- Adding `BaseData.AdjustResolution()` that should return a valid
resolution for the given data and security type.
This allows us to set a limitation which is useful to avoid invalid data
requests or unnecessary fill forward situations. The user will be
notified through a console message.
- Adding unit and regression test
- Updating example algorithms custom data resolution
- Some performance improvements. Wont change console color if
`SelectedOptimization` is defined
Updates all occurrences of parsing/ToString-ing to use CultureInfo if
possible. This project can not reference QuantConnect.Common, so it's
unable to use the new StringExtensions.
See #3045
Adds static methods of the form Parse.<TypeName>(string str) that use
CultureInfo.InvariantCulture. These are to be used when parsing strings.
It's still safe (from the CA1304/CA1305 perspective) to use the ToDecimal
extension method for decimals.
Adds string extension methods for common operations that will now require
CultureInfo.InvariantCulture. These are to be used when converting values
to strings, such as ToStringInvariant()/ToStringInvariant(format), but also
useful for searching within strings, StartsWithInvariant, EndsWithInvariant
and IndexOfInvariant.
FxCop has various rulesets for enforcing things within our codebase.
For this particular issue, we'll be enforcing CA1304 and CA1305 to
ensure we're always using an IFormatProvider or a CultureInfo where
applicable.
Linked Issue: #3045
Launcher project is packed as `QuantConnect.Lean`but as a mean ot having all Lean features just calling one package.
In the same sense, `QuantConnect.Algorithm.CSharp` is included as package and added as dependecy in the `QuantConnect.Lean` package just to have a working example aailable out-of-the-box.
In the advanced build settings, Language version was also upgraded from C# 5.0 to C# 6.0. The minimum Visual Studio version required will now be VS2015.
The console log handler specified a date format. I've updated the
implementation to add a constructor overload that accepts a different
date format. This can be useful when you're trying to see how precisely
timed some things are, such as testing for microsecond level accuracy
of events being fired :)
The previous implementation accepts an array of log handlers which
is great, however, it lends itself to some sticky syntax.
Specifying params here makes some call sites cleaner and more
intuitive.
Reorganised Lean Desktop to be launched from the Launcher.
Moved UI Layout to mainly use VS Winforms Designer.
//TODO reorganise Result Handler properly.
Many places in the code used Log.Error(err.Message) or equivalent which
strips out all the really useful information, such as the stack trace
and inner exceptions. Using Log.Error(exception) is the correct way to
log an error as it will correctly write all the message details, also,
by passing the full Exception object we can improve the logging in this
one place and all call sites will automatically benefit from the improvements
michael-sena