How is Main(...) called in referenced project? - asp.net-core

I'm learning Blazor and using this well known example:
https://github.com/aspnet/samples/tree/master/samples/aspnetcore/blazor/FlightFinder
The FlightFinder.Server project gets started and somewhere the referenced FlightFinder.Client project has the Main method called in its program.cs which builds/runs another host.
I can't figure out where this happens and I've been trawling through the documentation and Google for hours. As far as I can see there is no direct reference to that method in the FlightFinder.Server project.
Either I'm missing something or maybe this is such common knowledge nobody has written it down anywhere. I thought it might have something to do with UseClientSideBlazorFiles or MapFallbackToClientSideBlazor but I can't see how it works.
Please help me not go insane and understand.

Related

Reference not found after switching from Debug to Release mode

I have a problem with several references in my VB.NET project.
For example I have this line of code:
Dim m As New Chilkat.Email
It comes from the library "ChilkatDotNet45.dll".
When I click on "References" and locate this dll, I can see that it has the settings "Use local copy" and "Do not include interop types".
When I switch to Release mode, the compiler tells me that "Chilkat.EMail" is not defined.
I have this problem with several DLLs, so it is not specific to Chilkat.
Can somebody tell me what I did wrong?
Thank you.
One of the standard approaches to solving any programming-related issue is trying to reduce the scope of the investigation. If you have a big project, in which something doesn't work, try to create a smaller project, and try to replicate desired functionality in it. Reduce as much as possible, down to a brand new project with maybe 5-10 lines of code in it.
If you were unable to solve your problem after making a reduced test case, now it's good time to post it on StackOverflow. I am usually reducing problems while writing a question on SO (not before, as one might think), constantly thinking "ok, is it minimized enough"; and this is how 90% of the questions never get posted - I often find a solution along the way of reducing my question to bare bones. :)
In your case, can you build a simplified project which has this problem and post a link here? We could then try switching Debug to Release on our machines and see if the we can reproduce. There are too many options to do the guesswork.

Type reference forwarding in the MonoDroid project requiring it

Regarding to the solution described in this post, a third assembly is required to forward the type resolution to the correct assembly.
When adding this reference to the Android class library project using the type, the forwarding seems to not be done. The reference needs to be added in the Android application project which is the end point of the build process.
Does any solution exist to add the reference embedding the forwarding in the project requiring it ?
I mean, if in my solution architecture I use :
MyApp.Core - PCL
MyApp.Core.Droid - Android class library
MyApp.UI.Droid - Android Application
The usage of System.Net namespace (System.Net.Socket.AddressFamily for example) is done in my ViewModel, which is located in MyApp.Core.Droid (redirection of MyApp.Core with some plugins). In this case, it is more logical (and readable) to have the reference in the MyApp.Core.Droid. But in the fact, the assembly resolution is done (from what I understand) when packaging the application, so in MyApp.UI.Droid. So in this case, the reference needs to be added to MyApp.UI.Droid in order to be found (failed if added to MyApp.Core.Droid).
In this case the solution works, but its quite obvious to understand for a new programmer joining the team which, has not been facing the trouble and understands why this reference needs to be added to the UI project...
I'm not sure my thought is easy to understand by the way I introduce it. Let me know if you need more explanation.
Thanks,
Guillaume.
I'm not entirely sure why this 'fails if added to MyApp.Core.Droid' - it feels like this should be added. However, I know that Xamarin have tweaked and changed the dependency resolution scripts a few times.
With that said, I think the best answer to your question is 'don't worry about it too much' - this is only a small inconveneinve right now and it will be resolved by Xamarin's updates 'soon'.
The current PCL support is something that I and a number of others have worked on in order to make things work. This set of 'hacks' is a workaround for the lack of 'proper PCL' support - it simulates what the Microsoft PCL build platform does on WindowsPhone, WPF, etc, but it isn't a perfect implementation.
Xamarin have now committed to 'proper PCL' support. When that happens then these type-forwarding dependencies will automatically be added. The good news is that this support is perhaps now only days, weeks or at most months away.

How to create documentation for instance variable and methods in Xcode?

I'd like to be able to Alt-Click an instance variable (or a method) as part of the program i created and read what it's purpose is.
The fact that Xcode is telling me the class variable is declared at - is nice but not enough. In this case i'd like to see custom text i typed to describe what an asset really is. Additionally type of the ivar would also be useful to know.
How can this be done? In this case, i wonder what exactly did i mean by assets
I specifically wonder if this information can be viewed from inside Xcode, similar to how Eclipse shows JavaDoc content.
You would need to create a documentation set for your project and install it in Xcode. appledoc can help you with this. This is a command-line tool that can generate documentation in Apple's style from specially formatted comments in your headers. You can also integrate this into your build process with a run script build phase, so that documentation is always up-to-date.
For small projects, it's usually not worth the effort though and you're probably better off just adding comments to your header files and jumping there with Cmd-click (Ctrl+Cmd+left-arrow to go back to where you came from).
You'll probably want to take a look at Apple's documentation on Documentation Sets as well as their article on generating doc sets using Doxygen. The latter is based on Xcode 3.x, so how relevant it is is somewhat questionable, but it'd be a good idea to take a look nonetheless.
That said, if you decide to use Doxygen (alternatives like HeaderDoc can be used for documentation, but I'm not sure what's available to you as far as creating doc sets goes), it looks like the main point is you'll want to throw GENERATE_DOCSET=YES into your Doxyfile (or whatever you decide to call it). After that, you'd just throw the results into ~/Library/Developer/Shared/Documentation/DocSets (according to Doxygen's documentation). I don't know whether this works in Xcode 4.x - it's worth a shot though, and it'd be nice to hear back on it.
Note: most of this was based on this answer by Barry Wark. Figure credit is due there, since I wouldn't have bothered looking into this were it not for his answer.

Difference between (plain) Classworlds and Plexus Classworlds?

Can anyone please explain the difference between plexus-classworlds and (plain) classworlds?
These two are confusing and can't see the difference. Plexus classworlds contains almost no description. Apparently, a maven-based Java project uses both, I don't understand why.
Is it possible to replace classworlds with plexus-classworlds without much hassle?
I'm gonna answer that, even though the question is so old...
classworlds was migrated to plexus-classworlds, but the documentation on the site doesn't seem to keep up with that... the best docs I've seen was on classworlds 1.1-SNAPSHOT, although the current is plexus-classworlds 2.4.1-SNAPSHOT, and there is hardly any doc there.
if you look at plexus-classworlds, you can also see the original org.codehaus.classworlds package, with class comments like this:
A compatibility wrapper for org.codehaus.plexus.classworlds.launcher.Launcher provided for legacy code
which means that they thought about migration, but of course nothing replaces a thorough test.

Having trouble debugging class library plugin

I have a windows form application in which I'm attempting to utilize a plugin (class library). In the code I have it load the assembly from a dll file, which means I have not been able to debug. Furthermore I have not found out how to compile the library so I've had to use the debuged dll version for testing. I've run into a bug in which I create a new object and send that data through an interface to the plugin in an attempt to retrieve a blank slate group box from the plugin. However instead of reading the parameter as a new object i managed to step through the code once (don't ask me how, I don't know and I haven't been able to repeat it) and it appeared that the code was registering the parameter as "nothing" thus why I received a null reference error in the main program.
Is there a better way to debug this mechanism and find out where the problem is? Any ideas on what the problem could be. As I read over this is seems somewhat vague and I'm not sure how to describe it, but I'm willing to host a connect now meeting if anyone is willing to look at what is going on and I'm not making myself understood very well.
I'm not sure if I follow exactly what you're doing but I usually find that the best way to debug a class library is by in the solution for the class library I add a new project, either a WinForms one or a Console one, I then set this new project as the start up project and add a reference to the Class Library project (via the Project tab in the Add Reference dialog).
You'll then be able to call the methods in the class library from the other project and you can put breakpoints anywhere to see what's really going on easily.
Ok, so the problem was that any time you edit the class library you have to compile (and the only way I know how is debugging, I can't find a compile button and the publish button doesn't work and building doesn't appear to make a dll). But anyways you have to compile, transfer the file so you are reading the most recent one. If you edit the code during runtime it does NOT update the dll in use...which was my problem.