Twitter Yoda Bot
Yes, yes.
Launched a twitter bot, I have. Send you words of wisdom when tweet #yoda you do.
Sharing C# .NET assemblies and classes with a Silverlight project - reusing common code
Generally you wouldn't want the business logic placed into a Silverlight application... except for instances like mimicking a pure desktop application. For example a twitter client, video games, or other types of Silverlight applications that won't require any shared user data access (in the case of twitter, that is your backend). That being said, there are ways to share client and server code for a Silverlight project using a WCF back end.
Moving existing code to Silverlight (reusing old C# code)
If your project fits this description, you can modify the .csproj file to switch it between using the standard .NET assemblies and the Silverlight assemblies.
The key to switching the build type is finding this line in the non-Silverlight assembly project's .csproj file:
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
and changing it to:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\Silverlight\v3.0\Microsoft.Silverlight.CSharp.targets" Condition="" />
Now your project will be using the Silverlight assemblies, but some of the <References> lines in the csproj will need to be removed or changed. Here is what a typical Silverlight project has for the references:
<Reference Include="System.Runtime.Serialization" />
<Reference Include="System.Windows" />
<Reference Include="mscorlib" />
<Reference Include="system" />
<Reference Include="System.Core" />
<Reference Include="System.Xml" />
<Reference Include="System.Net" />
<Reference Include="System.Windows.Browser" />
If your project references any other assemblies that you have written, or any 3rd party assemblies, you will have to remove those references or perform the same csproj operation on them so that they are built against the Silverlight assemblies as well. All assemblies used by a Silverlight application must have been built against Silverlight .NET assemblies. If you try to add a reference to an assembly that did not, Visual Studio should display a warning.
Sharing source code via two proxy projects
If you want the source code to be shared with the server logic and client logic (maybe validation), then you can create two separate Visual Studio projects. Place the .cs files in a common/shared folder path, and when you 'add existing item' to the project you will use VS's "Add as Link" dropdown (the 'Add' button on the Add Existing Item screen has a dropdown arrow on it). Now you can have two primary projects (one Silverlight, one full .NET / WCF) referencing either of the new projects built on different platforms(one Silverlight, one full .NET / WCF), but the source code will be the same for both projects.
Also worth mentioning is the patterns and practices Project Linker Tool located here: http://msdn.microsoft.com/en-us/library/dd458870.aspx
Prism / Composite Application Guidance for WPF and Silverlight
Sharing code between WPF and Silverlight for a small utility class may work short term, but you will want to examine Prism - the Microsoft patterns and practices Composite Application Guidance located here: http://www.codeplex.com/CompositeWPF