I would like to use Castle Windsor 2.0 as the inversion of control container for my application and log4net 1.2.10 to provide logging services. Some Google searches suggest that Windsor provides some logging facilities and that I am supposed to create a public ILogger property on the classes that Windsor is instantiating. That sounds easy enough, but what do I need to add to app.config so I will get an ILogger that uses log4net?
The examples I have seen seem to come from an older version of Castle Windsor since they reference DLLs and namespaces that are not in the distrubution I downloaded. In particular, I do not see and Castle.Facilities.* namespace that contains logging objects. Some of these seem to have been moved to Castle.Core.Logging?
Any help is appreciated.
UPDATE:
Based on the answers below and further research, here is my current understanding.
Castle Project package release 1.0 RC3 includes many different components, including the MicroKernel, Windsor, and Services projects. The log4net integration I want is from the Services project. So, if I were to download the 1.0 RC3 package, everything I need is in one nice package.
However, the 1.0 RC3 version is really old.
As of some time relatively recently, the Castle Project components are only offered separately. Since I downloaded only the Windsor 2.0, I would not see the latest and greatest version of the Services project. Furthermore, the Services project has not had an official release since 1.0 RC3. I am not sure if I can just reference the 1.0 RC3 version or need to build my own from the latest code.
Here is a exaclty what you need as well I believe: Where & How Castle Windsor sets up logging facility
To use the logging facility with Castle Windsor 2.0 you have to pull the source code from the subversion repository (http://svn.castleproject.org:8080/svn/castle/tags/Windsor-2.0) and start ClickToBuild.cmd
The necessary assemblies (Castle.Facilities.Logging.dll, Castle.Services.Logging.Log4netIntegration.dll) can then be found in \build\net-3.5\release
If you do not want to pull the source and build it yourself, you can go to http://www.castleproject.org:8090/ and download the build artifact of the Windsor 2.x Release build.
Related
I'm trying to wrap my head around how we're supposed to build Azure functions.
I love the idea of building serverless, compact, single-function apps that respond to events.
Here are the problems I'm running into:
I have nice class libraries built in .NET Standard 2 that handle all my "backend needs" namely handling CRUD ops with Cosmos Db, Azure Table Storage, Azure SQL, Redis, Azure Storage. No matter what I did, I couldn't integrate these class libraries into an Azure Functions project. More details below.
Also, getting dependency injection in Azure Functions project has proven to be quite a task -- especially with my class libraries mentioned above.
At this point, the only option I'm seeing is to "copy and paste" code into a new Azure Functions project and use it without any DI.
This seems to go against "best practices". So what's the solution other than either to create monolithic code or wait till Azure Functions support .NET Core and DI.
I thought I could use my .NET Standard class libraries from a regular Azure Functions project targeting .NET Framework. After all, the idea of .NET Standard is to "standardize" things. I opened a couple of posts here on SO. I'm providing the links so that you can see the issues I've run into:
Using .NET Core 2.0 Libraries in WebJob Targeting .NET Framework 4.7
No parameterless constructor error in WebJobs with .NET Core and Ninject
P.S. My previous posts are referring to WebJobs. That was plan B approach because WebJobs seem half a step ahead of Azure Functions when it comes to supporting things like .NET Core and DI. Ultimately, I'd like to build a few Azure Functions that can use my class libraries built in .NET Standard 2.
Also, my previous posts mention that my class libraries target .NET Core 2.0. Since then I converted them to .NET Standard 2 which didn't really take much at all. I did this so that I truly conform to .NET Standard 2.
One issue is that Visual Studio has an outdated version of the Functions Core tools. Until this is resolved, you can work around in the following way:
Install the latest via npm by running npm install -g azure-functions-core-tools
In your Function App in VS, go to the Properties
Go to Debug, and click New... under Profile
Name the new Profile something like FunctionsNpm
Set the executable to (replace [YourUserName]): C:\Users\[YourUserName]\AppData\Roaming\npm\node_modules\azure-functions-core-tools\bin\func.exe
Set the arguments to host start
Set the working directory to $(TargetDir)
In toolbar, look for the green triangle icon to change your current Profile to the one you just created:
Now when you run from VS, you'll be using the npm tools instead of the older one that come with the VS package.
.NET Standard 2 support is on its way, see this github issue.
I'm using Mono For Android (probably will use MonoTouch too soon) and MVVM-Cross to port of a Windows Store app (Work on progress by another team, in Parallel).
Unfortunately the Windows store app team started of without using MVVM-Cross. That lead to some Windows specific libraries (like Windows.ApplicationModel.Resources) being scattered across code that should be portable across other platforms (for eg "Windows.ApplicationModel.Resources.ResourceLoader" was used for localization).
I was wondering if there's a cross-platform alternative (or may be a mvvm-cross plugin) for some of these windows libraries. Or may be guidance on how to create my own plugin/alternative.
There is a resourceloader plugin which uses windows package content files and android asset files.
See https://github.com/slodge/MvvmCross/blob/v3/Plugins/Cirrious/ResourceLoader/Cirrious.MvvmCross.Plugins.ResourceLoader.WindowsStore/MvxStoreResourceLoader.cs
It is used in (for example) the customer management sample in order to load an XML data file - see https://github.com/slodge/MvvmCross-Tutorials/blob/master/Sample%20-%20CustomerManagement/CustomerManagement/CustomerManagement/Models/SimpleDataStore.cs
It's also used internally in the json i18n plugin.
If you want a different implementation on one platform, then you can override the plugin for just that platform.
If you want a different implementation on all platforms, then it should be easy to create your own plugin, or to inject implementation of an interface on each platform. See the explanation of mvvmcross IOC in Instantiation of ViewModels and Service classes
Is it possible to run servicestack's built-in clients on the .net client profile framework?
When i change the target framework property in the project settings to ".Net Framework Client Profile" and try to compile i get the following message: the namespace ServiceClient does not exist in the namespace servicestack.
We use servicestack services to send exception reports. We use the JsonServiceClient and feel really comfortable with it. We could change the target framework - but then we have to check all installations for the availability of the full .net framework.
Any idea how to solve this?
Thanks.
From the package contents of the latest ServiceStack.Common package there seems to be no -client version included (See Common Framework and Profile Targeting Examples under NuGet - Creating and Publishing a Package).
You should either change the target framework the full profile or pull the code from ServiceStack's GitHub Repo and try to build it for client profile yourself. The downside of this is that you will loose Nuget's awesome update features...
You could off course file an issue at GitHub for the guys maintaining ServiceStack to add a client profile version of the framework, but I guess that there's a good reason for why it's not there already.
What's the difference between these two assemblies and when should I use each? I find that there are class name collisions between them so I imagine that I should only use one.
Example
Microsoft.WindowsAzure.Storage has Microsoft.WindowsAzure.Storage.Table.CloudTableClient
Microsoft.WindowsAzure.StorageClient has Microsoft.WindowsAzure.StorageClient.CloudTableClient
This seems very confusing. I can't imagine that Microsoft intends these to both be used in the same project.
Microsoft.WindowsAzure.Storage is version 2.0 of storage client library while Microsoft.WindowsAzure.StorageClient is the older version. There have been many changes in version 2.0 of the library (some of them are breaking). If you're starting new, I would actually recommend using 2.0 of the library as I found it more intuitive and easy to use than the older version. If you have an application which makes use of 1.7 version of the library, before you decide to upgrade, I would actually recommend reading the following blog posts by Windows Azure Storage Team:
http://blogs.msdn.com/b/windowsazurestorage/archive/2012/10/29/introducing-windows-azure-storage-client-library-2-0-for-net-and-windows-runtime.aspx
http://blogs.msdn.com/b/windowsazurestorage/archive/2012/10/29/windows-azure-storage-client-library-2-0-breaking-changes-amp-migration-guide.aspx
http://blogs.msdn.com/b/windowsazurestorage/archive/2012/11/06/windows-azure-storage-client-library-2-0-tables-deep-dive.aspx
However please note that there're still some components that your application might be using which has a dependency on storage client library 1.7. Windows Azure Diagnostics is one of them. So for some time you will need to use both versions. Good thing is that you can use both versions simultaneously in your project.
Hope this helps.
EDIT:
I also wrote a few blog posts about migrating code from storage client library 1.7 to 2.0 where I covered some basic scenarios. You can read those posts here:
Migrating blob storage code: http://gauravmantri.com/2012/11/28/storage-client-library-2-0-migrating-blob-storage-code/
Migrating queue code: http://gauravmantri.com/2012/11/24/storage-client-library-2-0-migrating-queue-storage-code/
Migrating table storage code: http://gauravmantri.com/2012/11/17/storage-client-library-2-0-migrating-table-storage-code/
I download the latest copy of castle windsor. there are 2 folders, one is net40, another one is net40-client. which one I should use for my asp.net mvc3 application. I am using vs2010.
the tutorial I read from the castle windsor wiki web site tells me to use dll files in "net40" .
if I use NeGet to install the package. I notice It only has net40-client folder.
can some one please explain to me the difference between those 2 folders and which one I should use.
I think that net40 and net40-client are basically the same except the later does not depend on System.Web and, therefore does not have the per web request lifestyle.
I found this post that confirms that (kind of - it would be great if there were a definitive page somewhere that outlines the differences but I could not find one): http://www.mail-archive.com/castle-project-users#googlegroups.com/msg09398.html
Given you are in asp .net anyway I would suggest you went with the net40 version (as you will already be building against that profile).