@mansellan One reason your PR is failing tests is that your new constructor for ClassModuleDeclaration does not pass all optional parameters to the main constructor.
Btw, we have zero tests covering a situation like the one introduced by the subtypes of ClassModuleDeclaration having a sub declaration type of ClassModule.
There might be things breaking because of it.
In particular, there might be places that assume that the result of DeclarationFinder.UserDeclarations(DeclarationType.ClassModule) still contains these declarations, which is not true.
So, this change already started by @Comintern with the document modules, should be followed/accompanied by adding new tests for the subtypes for all features of RD dealing with class modules.
BTW, I don't think the model is quite complete even with this PR. #4338 suggests there should be another abstract type of ComponentDeclaration between Declaration and ModuleDeclaaration for project components that are not modules.
You know, I haven't seen a good answer for this anywhere. Is it possible to embed a pre-existing DLL into a compiled C# executable (so that you only have one file to distribute)? If it is possible, how would one go about doing it?
Normally, I'm cool with just leaving the DLLs outside and having ...
Yeah, they're just the Primary Interop Assemblies (PIAs). They are intended for distribution - they don't actually contain any Office code, they just wrap the COM types for existing installations.
> I got a report of a failure to build this repo, so I wanted to make y'all aware of the problem.
If you try to load `Rubberduck.sln` (or any individual project) in Visual Studio 2019 (Preview), it will fail. This is because `Sunburst.NET.Sdk.WPF/1.0.47` isn't compatible with 2019. From SunburstApps/MSBuildSdks#1, it sounds like Rubberduck should consider migrating to a different approach.
As mentioned there, one option is to wait for .NET Core 3.0 and its associated SDK, which [will suppo
"Doctor, it hurts when I do this" - "Well then, stop doing that!" ...we just barely got 2017 to build RD semi-not-too-flaky. I'd prefer we hold off on 2019 for a while...
> Thanks for reporting this. As it stands, I think waiting for .NET Core 3.0 is the thing we want to do. We spent a lot of time to get the csproj files to the "new csproj" format, removing the Sunburst Sdk would imply at least partially reverting that effort.
Sunburst was initially intended as a crutch until the new csproj format supported WPF and WinForms builds correctly, as such this issue is a useful reminder to pay off that particular technical debt :)
@Duga I'm taking this one into my list of stuff, especially considering I wanted to check out Cake for building the ducky and touching that kinda lends itself well to also touching the VS2019 support ...
Now I only need to get through my backlog of real life issues and then I may even be able to get some stuff done on RD
I won't be able to finish the 2.4.1 release this weekend if I don't get it done tonight...
I'm supposed to get the thing into a working state ASAP. Aside from that I'm pretty much free
The working state thing means I get to keep most of the old mess around for a large component that's critical and entails herculean efforts to refactor
The vast majority of the others are all "FP doesn't do anything useful", and don't even realize the favorite parts of their language are inspired by FP (looking at C# devs here).
It even came up at work yesterday. Someone said "MS supports F# for azure functions. I disagree with them and don't think they should've supported it."
They are pretty cool, actually, and can do a lot of things, but this person didn't get that it would actually run on any .NET DLL that implements the right interface(s), regardless of the parent language.
Or however you mark it as an azure function; I don't quite remember that bit from his presentation--but I'd need to look it up myself if I used it anyway, so..
It uses attributes everywhere to mark inputs/outputs. I'm beginning to hate attributes.
ASP.NET supports them on view models to handle data validation on the front end automatically. EF uses them to designate keys and stuff if you don't do the fluent-API or whatever it's called, which is much nicer.
If you aren't careful, you can end up with like 3-5 attributes on a single class.
And I'm just laughing in my sleeve since C# is borrowing FP tools left and right.
C# 8 nullable references is basically because they saw how successful FP languages with their monad thing for that.
Pattern matching, Linq, even async/await.
That was added after they saw how cleanly F# had it.
TBF, it's probably far easier to support it in stateless FP languages.
But still, they, as a general rule have better support for asynchronous programming. Some to the point everything is async by default and the user can't even opt out.
Right now, I miss having you guys tell me that my tests are testing too much.
[Fact]
public void Update()
{
var foo = new Foo();
var fooData = new List<Foo>
{
new Foo()
}.AsQueryable();
var foos = MockDbSetCreator.MockDbSet(fooData);
var bars = MockDbSetCreator.MockDbSet(new List<Bar>().AsQueryable());
var context = new Mock<ProgramDatabaseContext>();
context.Setup(s => s.Foo).Returns(foos.Object);
context.Setup(s => s.Bar).Returns(bars.Object);
var controller = new FooController(context.Object);
var result = controller.Create(foo);
I think that's somewhere between 2-5 tests.
And I might switch to NUnit so I have Assert.Multiple.
Because some of these do make sense to be in one test.
For example, the top two go together, and 3/4 are both just making sure the right DB methods get hit.
and im in a situation where i dont get to do any "real" programming, and i dont have time to try to make VBA code similar to real programming in the way everyone here talks about
PARAMETERS cid TEXT (7)
,ct Long
,cta Long
,pid TEXT (7)
,c BIT
,ag BIT
,en TEXT (35)
,dop BIT
,pp BIT
,em BIT
,con BIT
,eh BIT
,es BIT
,mp BIT
,lu DATETIME
,lub TEXT (35)
,ds longtext
,vr bit;
INSERT INTO dbo_Engineering_Trace_ChangeIdHeader (
ChangeId
,ChangeType
,ChangeTypeAllowed
,ParentChangeId
,Complete
,AutoGenerated
,Engineer
,DrawingOfProduct
,ProductionProcedures
,EngineeringMaster
,ChangeOfNotification
,EquipmentHardware
,EquipmentSoftware
,ManufacturingProcess
I got googly eyes right now. Talking with my co-worker that has C experience, he's confident we could convert the Excel Workbook into its own dedicated environment.
Hmm interesting. Would have liked to see how that was done.
I usually figure that calling an external assembly to do calculation from a query would be more likely to kill the performance, not improve it, due to the overhead associated with marshaling data across the boundary often.
Even if it's unmanaged, it still would have to be a COM call, I think.
I think the longs and doubles generally don't need marshaling
it's usually the strings that is problematic since you must use COM functions to manage those strings
but in the end, you would still have to read individual pieces out of the internal structure into a marshal-able variable, pass it, let it do its thing, get the return back and transform it back to the original structure.
Calling such function from an Access query or an Excel worksheet function would necessarily traverse the boundaries for each invocation needed and that extra overhead can quickly add up
Are we looking to replace the DeclarationType enum with an inheritance hierarchy in the short or long term? I feel like maybe my PR has landed in the first stages of that... Should I be looking at reworking tests in that direction?
VBA Rubberducking
VBA Rubberducking