I wrote a an aspect called [NLogMethods] that logs method boundry to nlog, based on the example from Postsharp website.
I'd like to apply it to multiple DLLs in my infrastructure, for use in some of my applications.
in order to do this - I need to check out the project file of each DLL, add references to PostSharp, nlog and my aspects DLL, and add an attribute to AssemblyInfo.cs.
I rather not do it, but rather do it centrally in the application, or in an external tool.
Is there a way to apply the aspects (to entire assemblies) without editing those assemblies?
You can setup a batch script to apply the aspect on build.
http://programmersunlimited.wordpress.com/2011/08/16/exposing-internal-methods-in-3rd-party-assemblies-for-external-use/
http://programmersunlimited.wordpress.com/2011/07/27/applying-aspects-to-3rd-party-assemblies-using-postsharp/
You can also build a custom targets file, but I can't seem to find the reference for that.
Related
As the title says.
I use a couple of scripts that extend the Unity editor functionality, like SceneAsset class or TagSelector attribute, but now I just realized I can't build my project because of them and now I have to delete all of these and replace them with normal string and fill it myself, which I was avoiding until now.
Do I use these classes only for development? I know I can use #if UNITY_EDITOR #endif so part of the code will only work if built via Unity Editor, but in my case, this seems ugly because I want to declare fields via the inspector. Do I have to declare multiple fields for the same thing and separate the usage or is it possible to make two versions for one field so I don't have to change the code?
You can't have anything using UnityEditor in a build since this namespace is completely stripped of.
You only use it so you can implement editor scripts that simply only extend the functionality of the Unity Editor itself ... custom Inspectors/Windows etc.
Make sure you
Either put these in folders called Editor! these are excluded from the build automatically
Or use the pre-processors as you mentioned
Serialized fields should be used for both, editor and build (otherwise you will always get some warning about mismatching serialization layouts). If you need them for the editor, just keep them for the build as well even if they are not really of use there - they don't hurt and nobody will see them anyway.
I'm trying to create a fiddler Inspector2 and IFiddlerExtension in the same assembly. However, I can't get the extension to load if I host the assembly in the /Fiddler2/Inspectors/ folder and the inspector won't load when hosted in the /Fiddler2/Scripts assembly. Alternately, is there a way to manually inject, let's say, the inspector in the OnLoad code in the extension (or vice versa)?
I suspect the answer is no, but does someone know if it is possible to get Fiddler to load both types from the same assembly?
Background:
I'd like to be able to provide an inspector that will provide some visualization of a given response, while an extension hosts a new tab that will configure and provide analysis over the entire set of sessions.
If I need separate assemblies, I will likely need three since I'll have common code factored into a shared assembly and then the two assemblies to be put in different locations. It's a lot of extra work for a small assembly with only a handful of types.
You're correct to note that Fiddler's partitioning of extension types makes it difficult to offer both FiddlerExtensions and Inspectors in a single assembly today.
Technically, there's nothing stopping your Inspector object from manually creating and managing a top-level tab, since the primary point of the IFiddlerExtension interface is to get your code loaded in the first place, and Inspectors are already loaded anyway.
In the future, this could conceivably be problematic as I hope to offer "delay-loaded" extension types, but that feature would almost certainly be opt-in and thus not likely to break you.
I'm currently working on a little pet project that takes a code file and deploys it using NuGet. I can currently replace the namespaces in the project using the $rootnamespace$ token and the .pp extension, but I'm curious if there is a better way.
My chief complaint is that I have to take code which builds correctly and transform it temporarily into something that no longer does so.
Is there a way for me to perform these transformations without having to alter my source code directly?
So, I created a very simple NuGet Preprocessor that looks at my solution and creates a shadow copy that has been tokenized and transformed to adhere to the NuGet standard. Works like a charm and now I can very easily deploy source files directly.
The problem we have are as follows:
We are using ANT to build our application. However, the application is built multiple times, once for each client (they have different skins / cms / i18n etc). Up to now, we had no need to compile them all at once (usually just work on one client at a time). Now, we want our build server to build all permutations for all clients in all languages. In other words, we need to create a war file for each client, each containing their own compilation.
At the moment, the client name is read in from the application's .properties file.
My question is this. Is there any way that the client.name property (from the application's .properties) be overridden in the build.xml used by ant? Or is the only way to create a different target for each client and hard-coding the name?
Thanks.
If you use Hudson to do your build, and have more than one parameter to change, you should be able to do a Matrix Build. There is more detail in this answer.
If it is just one parameter, you should be able to do a properties file and use Ant to read this properties file and iterate through it - I'm not sure precisely how, but you won't be the first person to have this problem, and if you are it wouldn't be difficult to create your own task. Or if not use Macros.
I have a web application project. I want to add Configuration Source and keep Validation block, Caching and Logging config files separate. But as soon as I go to the UI of enterprise Lib and add a configuration Source, it combines everything in a single file. Is there a way to separate all these ?.
Yes you can separate the configuration files. This article gives some directions.