What happened to the Rx Switch() operator? - system.reactive

I am working my way through the Hands-On-Labs for reactive extensions (Rx HOL .NET.pdf) which I downloaded from the data developer center (here) a few days ago.
I added these references to my project, using NuGet:
System.Reactive 1.0.10621.0
System.Reactive.Windows.Forms 1.0.10621.0
I'm almost done with the labs, but I've hit a snag trying to implement the .Switch() example, Visual Studio can't locate the extension method:
'System.IObservable'
does not contain a definition for
'Switch' and no extension method
'Switch' accepting a first argument of
type
'System.IObservable'
could be found (are you missing a
using directive or an assembly
reference?)
Now I know this Hands On Labs document is out of date, because certain things have been renamed (FromEvent became FromEventPattern) and certain things were removed (RemoveTimeStamp) and this document does not reflect that. For the life of me I cannot guess what they renamed Switch to be, or figure out what assembly they might have moved it to, or find a comprehensive list of release notes that indicate it was removed.
Anyone know where I can find Switch and what it's current name is?

The Switch extension method doesn't extend IObservable<T> - it extends IObservable<IObservable<T>>. The full signature is:
IObservable<TSource> Switch<TSource>(this IObservable<IObservable<TSource>> sources)
Try typing Observable.Empty<IObservable<object>>(). and see if Switch appears then.
If not, check your using namespace declarations.

Related

Autofac Interface Ambiguity

"The ambiguity, is in the box" - Monty Python.
Autofac is having a problem resolving an interface. See attached solution.
The Interface, IAmbiguous, is defined in project ACommon. It is implemented in project AInjectable. The AInjectable project does not / cannot reference ACommon. The AInjectable project defines IAmbiguous as an existing item brought in with a file link.
The UI project calls ACommon Inject and attempts to register the AInjectable assembly. IAmbiguous is not ambiguous initially but after a builder.RegisterAssemblyTypes command it becomes "ambiguous in the namespace." There is no error thrown when the container is built but the registration is not there.
Registration can be done "AsImplementedInterfaces" if Named and Keyed is not used. But then there is no way to Resolve the registration because the service IAmbiguous is "ambiguous in the namespace."
This question was double-posted as an issue on Autofac. It is not an Autofac problem. I will copy/paste the answer from the issue in here; for future readers, if you want to see the repro solution, go check out the full issue
What you're doing by including the same interface in two different assemblies isn't something you should be doing. Note that by doing that, your AInjectable class is not implementing the interface from the ACommon project. It's implementing a different but identically named interface.
This sort of thing is a problem - having the same type (interface, class, whatever) name in two different assemblies. We even had a problem (#782) where we had a System.SerializableAttribute in Autofac as a shim for .NET Core. You really just can't do that.
You'll also see the same thing if you try to make a static extension method class that has the same namespace and name as some other static extension method class. Ambiguous references.
Without doing Reflection.Emit style code generation, you won't be able to declare an interface in one assembly ("Assembly A") and implement that interface in a different assembly ("Assembly B") without having Assembly B reference Assembly A. That's just how .NET works. What you're seeing is a manifestation of that when you use Autofac, but it's not caused by Autofac. It's caused by you doing something you shouldn't be doing in .NET.
The fix is to define your interfaces in a separate assembly that everyone implementing the interfaces can reference. (Or you can try to dynamically generate code using Reflection.Emit or Roslyn or something, but that's waaaay harder.)

What types can there be for "UDLText"s other than comments?

I am now using the Caché DB jar to query for class definitions (thanks #daimor; it was an eye opener) and in order to write the source files I need to also account for "UDL texts".
Now, all I have been able to understand of them so far is that they are comments found in the source you actually write in Studio. But then UDLTextDefinition defines .getCategory(); the only value I have seen this method return so far is "comment".
Is there any other possible value?
If you open source code for that class (%Dictionary.UDLTextDefinition), you will find CategoryIsValid method, and will see, that only two values are correct now, and it is comment and error. I'm sure you understand category comment. So, error used when developer managed to save source code with syntax errors in class definition, and that text will be in UDLText and with category error.

EF broken after update database. A namespace cannot contain members such as fields or methods

I have researched this topic and pulled up a couple of hits that I thought might have helped me. So far I am still pulling out my hair over here because everything was fine until I added a field to a table in Azure and then tried to update my model.
Here's a short sitrep of what the problems have been and what I have done to solve them.
Problem 1
Compiling transformation: Metadata file 'C:\Program Files\VS2013\Common7\Tools..\IDE\Microsoft.Data.Entity.Design.dll' could not be found
Compiling transformation: Metadata file 'C:\Program Files\VS2013\Common7\Tools..\IDE\EntityFramework.dll' could not be found
I solved the problem by changing my global environment variable in advanced system properties to the correct location of these files, which in my case was : F:\Program Files (x86)\Common7\IDE
This is probably due to the fact that I just installed VS 2013 ultimate on my F drive; however, I have been developing on it successfully now for a week and never had a problem until now.
After this I run into problem 2:
Problem 2
A namespace cannot directly contain members such as fields or methods C:\Users\Adrian.Campos\Documents\Visual Studio 2013\Projects\ConsoleApplication2\ConsoleApplication2\Model1.cs 1 1 ConsoleApplication2
As you can see the problem is arising from my Model1.cs class. My .edmx file is named model1 (fyi)
I found some links that weren't of help to me since my error is coming from a different source than that of the links.
VS2012: My Entity Framework model doesn´t get included to my project output using InstallShield
A namespace cannot directly contain members such as fields or methods.
A namespace cannot directly contain members... + Type or namespace definition, or end-of-file expected errors
That last link seemed the most promising; however, it did not fix my problem. What I do not understand is how in the world did everything just blow up after I updated my model?
Has anyone else experienced this and fixed it?

Problems compiling routes after migrating to Play 2.1

After migrating to Play-2.1 I stuck into problem that routes compiler stopped working for my routes file. It's been completely fine with Play-2.0.4, but now I'm getting the build error and can't find any workaround for it.
In my project I'm using cake pattern, so controller actions are visible not through <package>.<controller class>.<action>, but through <package>.<component registry>.<controller instance>.<action>. New Play routes compiler is using all action path components except for the last two to form package name that will be used in managed sources (as far as I can get code in https://github.com/playframework/Play20/blob/2.1.0/framework/src/routes-compiler/src/main/scala/play/router/RoutesCompiler.scala). In my case it leads to situation when <package>.<component registry> is chosen as package name, which results in error during build:
[error] server/target/scala-2.10/src_managed/main/com/grumpycats/mmmtg/componentsRegistry/routes.java:5: componentsRegistry is already defined as object componentsRegistry
[error] package com.grumpycats.mmmtg.componentsRegistry;
I made the sample project to demonstrate this problem: https://github.com/rmihael/play-2.1-routes-problem
Is it possible to workaround this problem somehow without dropping cake pattern for controllers? It's the pity that I can't proceed with Play 2.1 due to this problem.
Because of reputation I can not create a comment.
The convention is that classes and objects start with upper case. This convention is applied to pattern matching as well. Looking at a string there seems to be no difference between a package object and normal object (appart from the case). I am not sure how Play 2.1 handles things, that's why this is not an answer but a comment.
You could try the new # syntax in the router. That allows you to create an instance from the Global class. You would still specify <package>.<controller class>.<action>, but in the Global you get it from somewhere else (for example a component registry).
You can find a bit of extra information here under the 'Managed Controller classes instantiation': http://www.playframework.com/documentation/2.1.0/Highlights
This demo project shows it's usage: https://github.com/guillaumebort/play20-spring-demo

Can't switch between proto and implement in C++ project

I have use semantic-analyze-proto-impl-toggle to switch between the function's proto and impl, but when I use this feature it always doesn't do anything except saying that it can't find correspongding implement, the other feature like name completion is OK.Can anyone help me on this issue? And I really eager to know whether the semantic only parse the current buffer and the header files in include path, not parsing other implement files. I mean that whether semantic parses all the file in the project when it try to find the implement of a function.
The proto/impl toggle will look for symbols in all the files of your project that have been parsed so far. It runs into trouble when the sources don't have the right includes and you try to jump between methods. There is an explanation, with a hacky work-around patch on the mailing list here:
http://sourceforge.net/mailarchive/forum.php?thread_name=4FDBF890.8010505%40siege-engine.com&forum_name=cedet-devel