I have a solution with two projects Business and Domain I'm using Fody.EmptyConstructor to create parameterless constructors for my domain models on runtime. It works well when I add the Fody.EmptyConstructor package to the Domain project, but I'd rather not have that as a dependency there and instead have it in Business. Is there a way to do so?
-Sln
--Domain
--Business (has reference to Domain)
---FodyWeavers.xml
FodyWeavers.xml:
<Weavers xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="FodyWeavers.xsd">
<EmptyConstructor />
</Weavers>
Thanks in regard for any suggestions.
Fody needs to be installed in the project it modifies, along with its addins. It does not modify projects transitively, nor can it modify another project.
But it won't add a dependency if you add the PrivateAssets="all" attribute to the PackageReference items of Fody and EmptyConstructor.Fody.
Depending on how the weaver is configured, Fody will remove references to the weaver libraries. This is the case for EmptyConstructor.Fody.
Related
I StructureMap as a way to do DI in my project. I want to create sitemap in my project.
I install MvcSiteMapProvider MVC4 StructureMap Dependency Injection Configuration from NuGet.
it requires manual config but I don't know how to config this.
thanks for your helps
If you installed MvcSiteMapProvider.MVC4.DI.StructureMap into your project, it does not require manual configuration. This package is for use when you don't already have DI in your project - it contains a composition root which is meant to be used as the single place to register all of your DI configuration for your entire project.
However, if you installed MvcSiteMapProvider.MVC4.DI.StructureMap.Modules into your project, it requires manual configuration. This package is meant to be used in projects that have a pre-existing DI setup. You just need to follow the instructions in the readme file in order to add it to your existing configuration. The exact procedure and could vary greatly from one project to another, but the readme contains all of the required and optional lines of code that will need to be added. The key is that you need to ensure that only 1 DI container is instantiated for the entire project and that all of the modules are registered with it.
Do note that MvcSiteMapProvider.MVC4.DI.StructureMap depends on MvcSiteMapProvider.MVC4.DI.StructureMap.Modules, so you can easily downgrade with a single package manager command.
PM> Uninstall-Package MvcSiteMapProvider.MVC4.DI.StructureMap
Make sure you don't use the -RemoveDependencies option.
In our WCF solution we have one ConsoleHost (console application not class library) project and one WasHost Project. We use the Consolehost hosting for Dev environment and WAS hosting for production.
Now there are a number of .config files that are included using "include uri=file://services.config" in the Castle section of ConsoleHost project. I don't want to make a copy of this services.config file in the WasHost Project.
Is there a way to include files from other projects without making local copies of them? Or happy to hear other better ways of doing this.
Thanks
Ravi
You could do this a couple of ways.
One is to simply add a link to the source file from both projects as described here.
Alternatively you could embed the config into one of the common assemblies (Build Action=Embedded Resource in the file properties) and then use Castle's ability to include embedded resources. E.g.
<include uri="assembly://AssemblyName/xxx.config"/>
I'm prototyping a WCF project using Spring.NET as the IoC container. It seems like I have to include explicit references to all Spring.NET managed assemblies I use in my IIS web.config.
For example, if my WCF project is referencing Spring.NET managed AssemblyA that is in turn referencing a Spring.NET managed AssemblyB, I have to include the following lines in my config file in order for all dependencies to be resolved:
<spring>
<context>
<resource uri="assembly://AssemblyA/ApplicationContext.xml"/>
<resource uri="assembly://AssemblyB/ApplicationContext-Dao.xml"/>
</context>
</spring>
Can't I package AssemblyA and AssemblyB in a such way that they "bootstrap" themselves, perhaps by using the app.config for each assembly? Forcing a consuming application to have intimate knowledge about the dependencies of it's dependencies seems really smelly to me and contrary to the principles of DI.
I can find no documentation on this.
Many thanks.
Assemblies don't have an app.config, so no.
I don't know how your code is layed out, but in theory the container should be instantiated in the main dll, so it would make sense that there is where all the configuration resides (or as in this case, where the links to the config pieces reside).
Following Situation:
2 Team Projects
Dvelop of Team Project A added Project References of Team Project B to their projects.
For speeding up the Build I want to replace the project references with referencing the dll's directly.
My Idea:
in the csproj of Team Project A:
<ProjectReference Condition="'$(IsDesktopBuild)' == 'true'" Include="[Project Reference] >...
in the TFSBuild.proj
<AdditionalReferencePath Include="[buildoutputOfTeamProjectB]" />
OR
Disable SolutionToBuild and use the csproj files directly.
Thanks for your suggestions.
I would suggest that each project have a dependencies folder that contains the appropriate dlls that are required for each project. When a project that is depended upon is built it would be up to you to automatically update the dll in the dependencies folder or not via your build process (cruise control/nant/msbuild?). However, I would also give some consideration around deploying versions of the depended upon dll just in case you blow up the dependent projects usage of that dll. It would suck for someone to update their project (the depended on project), kick off a build, deploy their build output to the dependent project) only to break the project that relies on their code base. That sounds like a fragile way of managing dependencies.
I have to deal with what is pretty ugly and large blob of ColdFusion code which up to this day is maintained by direct modifications on production server (don't ask). I managed to clean it up from dupes and backups and put it into Subversion, now I need tp pick a make system to be able to put this onto continuous build (TeamCity) and also scheduled releases.
To my surprise I only found pretty much a single blog article on how to retrofit CF project with Maven, so the question is - does anyone have experience successfully using Maven on CF and what in general people use to manage large CF projects?
Your suggestions, tips and links will be much appreciated
Since I don't want to start religions wars - Maven is pretty much company standard (vs Ant)
First, here's another blog you might find helpful.
build-tools-maven-and-coldfusion
I haven't tried to build ColdFusion with Maven, but I have experience with managing Maven builds for a large company. There are a few things for you to consider.
Project structure
Coldfusion cfm and cfc files should be put in src/main/resources so they are bundled in the jar (the blog referenced above overrides the Maven convention to put them in src. this is ok, but could be a problem if you later need to add anything else to the project).
I'd probably keep cfc and cfm files in separate projects with appropriate dependency declarations to link them, this keeps your cfc projects as libraries and helps reuse. It is also worth considering the granularity of the cfc projects. Generally Maven's dependency management helps you keep artifacts small, with little need to worry about finding all the jars.
Deployment
The simplest way to deliver the artifacts is to use the maven-war-plugin to create a war containing your artifacts and all their transitive dependencies. This makes each application self-contained, which can be useful. The downside of this is that you'll end up bundling the same artifacts repeatedly and they can be quite large. To mitigate this you can either use the assembly-plugin to create custom packages excluding the common components, or you can specify that certain components (e.g. ColdSpring) are scope provided, this means they won't be included in the war.
Version Management
Maven encourages a proliferation of dependencies, by default each dependency declaration has a version, this can cause maintenance issues, particularly when you want to bump the version of an external dependency. You can mitigate this by defining a parent POM or an "app" POM. Either would have a dependencyManagement section declaring the details (groupId, artifactId, and version) for common artifacts. Any POM inheriting from the parent need not declare the dependency version as it will be inherited (note this doesn't mean that all children will have all dependencies, only that any that declare a dependency don't need to declare the version). If you define an "app" project with packaging "pom" and a dependencyManagement section, you can reference it with scope import (from Maven 2.0.9 onwards), this will import the dependencyManagement section from the "app" project to the project POM. See the dependency documentation for more details.
If you declare a dependency with a scope in the dependencyManagement section, that scope will be inherited unless it is overridden in the child POM. Related to the deployment section above, this means that you can declare the common libraries scope provided in the parent to ensure they are not bundled in each applciation.
Naming Conventions
You'll need a naming convention for the packages to avoid collisions.
It's probably best to follow the Maven convention and use java package-like groupIds (org.apache.maven for maven.apache.org) and the jar name for the artifact. This convention would give the groupId "org.coldspringframework" and artifactId "coldspring" for ColdSpring.
Further distinctions might need to be made across the company. For example, if you have a web and core team, you could give the web team the groupIds com.mycompany.web.* and the core team com.mycompany.core.*
Dependency Management
You'll need to add your CFC packages to a Maven repository such as Nexus so they are accessible to other builds across the enterprise.
If you want to keep the CFC packages separate to the jars. You can specify a custom packaging type, so that they won't be mixed up with any Java artifacts. If you create a custom packaging type, the artifacts can have the ".jar" extension, but any dependency declaration must have the type set.
Here's an example following those conventions:
<dependency>
<groupId>org.coldspringframework</groupId>
<artifactId>coldspring</artifactId>
<version>1.2</version>
<!--custom packaging type helps keep separate from Java artifacts-->
<type>cfc</type>
</dependency>
There's a section in the Nexus book that describes custom lifecycles (follow the links for more details. Essentially you need to create a plugin with a META-INf/plexus/components.xml to describe the plexus mechanics (what archiver to use, what extension to output etc).
The components.xml would look something like this:
<component-set>
<components>
<component>
<role>org.apache.maven.lifecycle.mapping.LifecycleMapping</role>
<role-hint>cfc</role-hint>
<implementation>org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping</implementation>
<configuration>
<phases>
<process-resources>org.apache.maven.plugins:maven-resources-plugin:resources</process-resources>
<package>com.hsbc.maven.plugins:maven-jar-plugin:jar</package>
<install>org.apache.maven.plugins:maven-install-plugin:install</install>
<deploy>org.apache.maven.plugins:maven-deploy-plugin:deploy</deploy>
</phases>
</configuration>
</component>
<component>
<role>org.apache.maven.artifact.handler.ArtifactHandler</role>
<role-hint>cfc</role-hint>
<implementation>org.apache.maven.artifact.handler.DefaultArtifactHandler</implementation>
<configuration>
<extension>jar</extension>
<type>cfc</type>
<packaging>cfc</packaging>
</configuration>
</component>
<component>
<role>org.codehaus.plexus.archiver.Archiver</role>
<role-hint>cfc</role-hint>
<implementation>org.codehaus.plexus.archiver.zip.ZipArchiver</implementation>
<instantiation-strategy>per-lookup</instantiation-strategy>
</component>
<component>
<role>org.codehaus.plexus.archiver.UnArchiver</role>
<role-hint>cfc</role-hint>
<implementation>org.codehaus.plexus.archiver.zip.ZipUnArchiver</implementation>
<instantiation-strategy>per-lookup</instantiation-strategy>
</component>
</components>
</component-set>
Maven looked interesting to me too, but I couldn't find enough resources, and didn't have enough time to figure it out, so I moved onto what seemed to be good as well.
I understand you prefer to use Maven, I have come across several articles regarding Ant and Coldfusion, as well as a recent one about Hudson with Coldfusion.
Coldfusion also has the cfant (undocumented) tag. You can run ANT scripts right from CF?