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)
Related
Background, I currently use Izpack for my Windows installer, I bundle a java runtime and use winrun4j as a wrapper both for the installation and the actual program once installed. It worked for a long time but there are a number of problems with the installer that I have not been able to solve and have been looking to replace it.
Oracle now provide the JPackage installer so it seems like a sensible choice. But the folder structure created by the installer is different to what I currently have, I have a number of config and non java files and I have not been able to get the .exe that JPackage creates to do anything.
So is it possible to use JPackage to create the installer but in a strcuture better matching my existing structure, and use continue to use WInRun4j to actyally run my application
Existing Folder Structure
ROOT
---App.exe
---Config Files
---lib
-------jar files
---JVM64
------- Java runtime
---help
JPackage structure
ROOT
---App.exe
---Runtime Dlls
---app
----- jar files
Config files
--runtime
------Java runtime
------Runtime Dlls (again)
The structure of directories generated by jpackage is mainly set up for you and does not seem possible to change, and makes installation of Java app dependencies very easy with self contained JRE. The basic structure for Windows is as you say:
ROOT
---App.exe (for --main-class parameter)
---xyz.exe (for each --add-launcher parameter)
---Runtime Dlls (these appear to be unused except for applauncher.dll, see SO 62607300)
---app/
------App.cfg (for --main-class)
------xyz.cfg (for per --add-launcher)
---runtime/
------Java runtime
------Runtime Dlls
With --input and --main-jar params you are free to setup additional directory structure under app/ folder for anything else you want for your application. So if you used lib/myappjar.jar it would add:
---app/
-------lib/
----------myappjar.jar
If you used --input build\mypath it would copy the entire tree of files under that folder, so if build\mypath dir contained
bin/
---Scripts
---xyz.properties
README.txt
Then app would also contain:
---app/
------bin/
---------Scripts
---------xyz.properties
------README.txt
By the way the Runtime DLLs placed at top level appear to be copies of some of the DLLs under runtime/bin
[https://stackoverflow.com/questions/62607300/why-is-java-jpackage-installing-windows-dll-files-in-two-places]
i was able to publish the website to local machine folder, where i've the bin, content, scripts, views, web, global, and packages folder.
AFter i add these folders to the root of my web server using filezilla, the website does not work. server does support asp.net 4, ii7.
What exactly are the steps. i looked for some answers googling, but none of it helped. I'd realy appreciate if you can help me figure this out, thanks
UPDATE Issue Fixed: My project was using .net 4.5 instead of 4.0...which was causing the issue on the server where I was deploying my website
There are 2 steps in order to deploy your application:
1. If ASP.NET MVC 3.0 is not installed on the server you should deploy the following set of assemblies in the bin folder of your web
application:
Microsoft.Web.Infrastructure.dll
System.Web.Helpers.dll
System.Web.Mvc.dll
System.Web.Razor.dll
System.Web.WebPages.Deployment.dll
System.Web.WebPages.dll
System.Web.WebPages.Razor.dll
you can set copy local to true but this is not available for all listed dll's or you can use some interesting future: right click on the project and select Add Deployable Dependencies with ASP.NET checkbox checked.A special folder named _bin_deployableAssemblies will be created with all necessary assemblies copied into this folder. When the project will be compiled all this assemblies will be copied into bin folder.
2. Publish the application: in a local folder and copy it to your deployment server or directly via FTP.
Marking references as Copy to Bin Directory in the properties window will make sure that the DLL is copied to the /bin directory.
I have a machine which doesn't give me local admin rights. Is it still possible to run erlang on it, as I cannot run a windows .exe installer to install erlang?
You can copy erl.exe (plus the runtime system and all the libraries you need) from another installation and run it without the need to install. As long as you are allowed to execute files it should be okay.
Forgive me for not being as smart as Zubair,
but I would like to know exactly how to do this.
I do not have admin privilege, cannot run installers, and cannot copy files to C:\WINDOWS.
In particular, I cannot write to C:\WINDOWS\WinSxS or C:\WINDOWS\system32.
How do I get a list of exactly what libraries are required by the various erlang executables ?
I have all the MS redistributable libraries and manifests,
but I don't know where to put them to make it work.
The redistributable library structure has directories such as
Microsoft.VC90.ATL, Microsoft.VC90.CRT, etc. Each directory contains relevant dlls and a manifest.
Do I copy all the contents into the ERL_HOME\bin directory or ERL_HOME\erts-x.y.z\bin or ERL_HOME\erts-x.y.z\lib ?
or leave them in some other directory and put those entries in the PATH ?
or do I need to build the paths implied by the manifests (i.e. where they would be copied into the WinSxS cache) using hashes and version numbers in the paths, then put those entries in the PATH ?
I have developed an ASP.NET MVC 2 website, and now need to deploy it to my web server. I've overcome some hurdles already, since ASP.NET was not installed etc. but I've now got to the point where I can serve up plain content files, and if I try to hit one of my MVC URLs I get this:
Could not load file or assembly 'System.Web.Mvc, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
Not surprising, that, as I've not installed MVC2. Problem is, I can't find any good information about how to install it!
The Microsoft Download Center lists 3 files, none of which look promising:
ASP.NET-MVC-2-RTM-Release-Notes.doc
AspNetMVC2_VS2008.exe
mvc2-ms-pl.zip
The site doesn't bother to explain what the files actually are, but I assume that the last file is the source code. That's what it looks like, anyway. The release notes are no help whatsoever, since they're all about installing on your development machine, and indeed the name of the EXE makes it clear that that's all about Visual Studio integration too.
So how do I actually deploy the darn thing?
The other option linked to from Scott Gu's blog is the Microsoft Web Platform Installer. Now, I don't want to install more than just MVC2, and I already have IIS etc. set up, so this seems a bit heavy. But it's all academic, as it refuses to run on my server, saying "your system is not supported" or words to that effect. (The server is Windows Server 2008 Standard SP2, so I really don't know what it's problem is).
Help!
[It's ridiculous that this should be so hard - or perhaps not hard at all, but certainly a well-kept secret!]
To deploy an MVC application, you just need to ensure that you set the references up to copy to your bin folder. Specifically, these DLLs will need to be in there...
System.ComponentModel.DataAnnotations.dll
System.Web.Abstractions.dll
System.Web.Mvc.dll
System.Web.Routing.dll
Note: Copying a reference to your bin folder.
In practice, you do this by following these steps:
Right-click on the reference in
the "references" section of your
project
Select "Properties"
Locate the "Copy Local" property and
set it to "true"
PLEASE NOTE!
System.Web.Abstractions.dll
System.Web.Routing.dll
You only need these two if .NET 3.5 SP1 has not been installed - if you don't have SP1, you will need to include these two dlls, which are part of SP1 and are needed by MVC for routing.
The correct answer is given by Darin Dimitrov in this answer (posted here for your convenience):
You could do a server install which doesn't require Visual Studio installed:
msiexec /i AspNetMVC2.msi /l*v .\mvc.log MVC_SERVER_INSTALL="YES"
Now you are probably asking where's this AspNetMVC2.msi coming from. Actually you download AspNetMVC2_VS2008.exe from here, rename the .exe to .zip and inside you'll find what you are looking for (in the mvcruntime sub-folder).
Copy System.Web.Mvc.dll from your development machine to the application's Bin folder on the web server (or to the GAC).
This file comes from AspNetMVC2_VS2008.exe.
You do not need to put these files in the Server GAC. You can, but you don't need to.
You can simply copy these files to your /bin directory on the server. In fact, if you have Copy Local set to true when you right click on the reference, it will do just that.
You need to make sure the reference path to this file:
System.Web.Mvc.dll
is in your /bin directory.
I find running the web platform installer tool works great for getting servers and development machines running. It can be found here... http://www.microsoft.com/web/default.aspx
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").