Currently I have the same problem as: How do I get a MEF Directory catalog looking at the same directory for both the Servicelayer and DAL?.
I have a service say serviceWithMEF that initialises an MEF container. If this service is consumed by the web application project in the same solution, a relative path for the catalog such as ..\..\Extensions will search for the dll's two folders up from the web's root folder. However, if some other non-web project in the solution consumes it, it looks for the Extensions directory two folders up from \Debug\Bin instead.
I would like all projects in the same solution to look for the Extensions directory in the same place, without using absolute paths. serviceWithMEF currently gets the path ..\..\Extensions\ from the globalsettings.xml.
One possible solution I had was to create a symlink called 'Extensions' in all the projects folders and have the links point to the Extensions directory that the web application uses. However MEF doesn't seem to be treating the symlink as a directory.
var catalog = new AggregateCatalog();
catalog.Catalogs.Add(new DirectoryCatalog(Config.ExtensionPath));
leaves me with an empty catalog if I have a symlink that was created with mklink /D Extensions ..\..\Extensions, instead of an actual directory.
Any assistance would be appreciated
Related
I want to make Dart app that has flexible deployment. It can be started as a web server or standalone app in browser as well. My directory structure:
bin
- httpserver.dart
lib
- commonlib.dart
web
- web.html
- web.dart
pubspec.yaml
I wanto start either httpserver.dart providing web's content or web.html directly in Chromium. I have troubles with the lib visibility from bin/httpserver.dart. using the "import 'package:prj/commonlib.dart'" does not work. But from the web.dart is works fine.
Please advice how to share libs among bin's and web's code. Or I should I make structure of dirs somehow different?
Note: there is no packages sub-dir in the bin directory created by pub get. I am using dart sdk 1.7.2.
Thank you, Ladislav.
In the bin directory there should be a packages symlink created automatically but it is not in subdirectories of prj/bin. If the symlink isn't created just create it manually.
I've created ASP.NET MVC project in MonoDevelop on Ubuntu.
Using Nuget, I added LibGit2Sharp package, but it doesn't have libgit2 library compiled for linux environment.
Then I downloaded libgit2 sources and compiled them.
Now I have libgit2-06d772d.so, but when I put it into the bin folder of my asp.net mvc project, I get System.DllNotFoundException git2-06d772d
NOTE
When I create Console project and put libgit2-06d772d.so into the bin folder of this project, application works fine.
Shared objects are not loaded when they are next to a particular file, but when their directory is in the library load path. The operating system sets a few paths that are valid for all programs, but if you have your library elsewhere, you need to specify the directory yourself.
Exporting LD_LIBRARY_PATH with the dir of the library will let the library loader know what other paths you expect to load a library from. E.g. if you built libgit2 with the libgit2sharp script you might run
export LD_LIBRARY_PATH=$HOME/libgit2sharp/libgit2/build
in the console to let the OS know that any program you start from that shell where to find libgit2.
It's common for mono-based apps to provide a script for the user to run which sets up the environment before calling mono to start the actual .exe with the program.
I like Yeoman's features like the Package Manager (Bower), Livereload integration, Compass, etc.
Therefor, I'd like to use it to handle my public website. However, instead of using the "app" folder, I would like to put everything at the root.
I've changed the references in the grunt configuration file but still get errors when installing new package and building.
Is it possible to change the project structure?
Not as easy as it could be at the moment, but we're working on making it easily customizable.
Though I don't think you would need to. You develop in the /app folder and deploy the contents of the built /dist folder. That way it's still in the root on your server.
The app I work on needs to use the wpftoolkit.extended.dll (i.e. no source, no msi/installer, we've only got the dll). So far we've placed the dll in a c:\libs folder on both the dev's laptop and the teambuild server and it built ok on both; now for deploying we want to add it to an installer (.vdproj) and we think we'll need it in tfs's repository somewhere. However, when tested the app now only builds on the dev's laptop and not on the teambuild server (looks like a relative path thing).
So... rather than fixing the actual problem, I'm wondering what's the best/cleanest/commonlyAccepted way to do this? where should I keep the dll in the repository and where should I place the dll on the host we're deploying to?
You should use folder structure on the source control like the following
/Main Contains the .sln file
/Source
/MyApp1 Contains MyApp1.sln file
/Source Contain folder for all
/ClassLibrary1 Contains ClassLibrary1.csproj
/MyApp1Web Contains Default.aspx
/Build Contains build output (binaries)
/Docs Contains product docs etc
/Tests
**/3rdpartyDlls** Contains all vesions of third-party dlls
For more information about the source control folders and best practices, it's recommended to read the book patterns & practices Team Development with TFS Guide (Final Release)
I have an erlang application I have been writing which uses the erldis library for communicating with redis.
Being a bit of a newbie with actually deploying erlang applications to production, I wanted to know if there was anyway to 'bundle' these external libraries with the application rather than installing into my system wide /usr/lib/erlang/lib/ folder.
Currently my directory structure looks like...
\
--\conf
--\ebin
--\src
I have a basic Makefile that I stole from a friend's project, but I am unsure how to write them properly.
I suspect this answer could involve telling me how to write my Makefile properly rather than just which directory to plonk some external library code into.
You should really try to avoid project nesting whenever possible. It can lead to all sorts of problems because of how module/application version is structured within Erlang.
In my development environment, I do a few things to simplify dependancies and multiple developed projects. Specifically, I keep most of my projects sourced in a dev directory and create symlinks into an elibs dir that is set in the ERL_LIBS environmental variables.
~/dev/ngerakines-etap
~/dev/jacobvorreuter-log_roller
~/dev/elib/etap -> ~/dev/ngerakines-etap
~/dev/elib/log_roller -> ~/dev/jacobvorreuter-log_roller
For projects that are deployed, I've either had package-rpm or package-apt make targets that create individual packages per project. Applications get boot scripts and init.d scripts for easy start/stop controls but libraries and dependancy projects just get listed as package dependencies.
I use mochiweb-inspired style. To see example of this get your copy of mochiweb:
svn checkout http://mochiweb.googlecode.com/svn/trunk/ mochiweb
and use
path/to/mochiweb/scripts/new_mochiweb.erl new_project_name
to create sample project of the structure (feel free to delete everything inside src afterwards and use it for your project).
It looks like this:
/
/ebin/
/deps/
/src/
/include/
/support/
/support/include.mk
Makefile
start.sh
ebin contains *.beam files
src contains ***.erl files and local *.hrl files
include contains global *.hrl files
deps contains symlinks to root directories of dependencies
Makefile and include.mk takes care of including appropriate paths when project is built.
start.sh takes care of including appropriate paths when project is run.
So using symlinks in deps directory you are able to fine tune the versions of libraries you use for every project. It is advised to use relative paths, so afterwards it is enough to rsync this structure to the production server and run it.
On more global scale I use the following structure:
~/code/erlang/libs/*/
~/code/category/project/*/
~/code/category/project/*/deps/*/
Where every symlink in deps points to the library in ~/code/erlang/libs/ or to another project in the same category.
The simplest way to do this would be to just create a folder named erldir and put the beams you need into it and then in your start script just use the -pa flag to the erlang runtime to point out where it should fetch the beams.
The correct way (at least if you buy into the OTP distribution model) would be to create a release using reltool (http://www.erlang.org/doc/man/reltool.html) or systools (http://www.erlang.org/doc/man/systools.html) which includes both your application and erldis.
Add the external libraries that you need, anywhere you want them, and add them to your ERL_LIBS environment variable. Separate the paths with colon in unix or semicolon in dos.
Erlang will add the "ebin"-named subdirs to its code loading path.
Have your *.app file point out the other applications it depends on.
This is a good halfway-there approach for setting up larger applications.
Another way is put your lib path in ~/.erlang.
code:add_pathz("/Users/brucexin/sources/mochiweb/ebin").
code:add_pathz("/Users/brucexin/sources/webnesia/ebin").
code:add_pathz("./ebin").
code:add_pathz("/Users/brucexin/sources/erlang-history/ebin/2.15.2").