I've got Monoserve and Nginx running perfectly in Ubuntu however I still have to publish the website locally on a Windows box using MSBuild and then copy the files over.
Preferably I'd like to have a Linux CI server that does this instead using XBuild however I can only get it to build the project into .dlls, how do I publish and deploy it with js, css, views, etc?
Typically the "build dlls" part is the hardest part. If you've got that solved, you're 80% there. The other half is publishing content. In it's most elementary aspect, you're copying a portion of the files from the source dir to the website folder. MSDeploy is Microsoft's answer to it, and it's waaaaaay too complex. I built an NAnt task that does this, though that also doesn't apply to your specific scenario. However, the general methodology can:
Crawl the sln file looking for web projects. What makes a web project? Technically guids in the csproj file or project type ids in the sln file. I cheated and defined it as "the target folder includes a web.config file". If you've only got one website project in your solution, you can skip this step, and just hard-code the .csproj file.
Crawl the csproj file looking for <Content Include="some\file.ext" /> nodes. XPath could do this, Linq to XML could do it too. This gives you all the .aspx, .cshtml, .js, .css, .png, .config, etc, etc, while carefully leaving behind all the .cs files. You'll need to prefix the path to the .csproj file to get the true origin file location, and you want to ensure you preserve the folder structure in the destination location. But this is trivial in comparison to harvesting the file list.
Now that you've got the file list, loop through it copying from the source folder to the destination folder. (You probably want to either empty the destination folder first or afterwards prune extra files from previous deployments. I find the former easier.) The only thing the csproj file crawl didn't give you was the bin folder content, but that's cake: copy all the contents of the bin folder. :D (There's a healthy debate about whether to copy .pdb files, but I say yes.)
Form a script to do the above 3 steps, then call it either from an XBuild task or call both XBuild and this script from the CI process. Poof. You've got a deploy target. Happy coding!
Preferably I'd like to have a Linux CI server that does this instead using XBuild
The good news is that you CAN do this with a workaround I found in this article. Here is an excerpt and the workaround link from the above article:
The build server does not have Microsoft MVC (any version) installed.
However, this is very easy to work around-Microsoft MVC is available
on NuGet at http://nuget.org/packages/Microsoft.AspNet.Mvc if you need
to install an older version, click on the older version at the bottom
of the page and you’ll reach instructions on how to install that
version of the framework.
Hope this make it easy for you!
#DHarun 's idea works great!
I just wrote a small script based on #Dharun 's idea, hope it may help others.
https://github.com/z-ji/MonoWebPublisher
Related
I have a fairly large solution with a mix of assemblies and ASP.NET websites (the ones without a csproj file). I'm trying to customize the build from the command line, and so I need to understand what exactly MSBuild is doing.
When MSBuild builds .sln file, I see that it creates metaproj files (which I assume are MSBuild files). However, they never seem to appear on the file system. I assume that MSBuild keeps them hidden in some way. Is there a way that I can view these files?
use the following environment variable:
set MSBuildEmitSolution=1
Some "under the hood" basics for Web Site projects that gets lost the way MS organizes their docs...
When MSBuild is executed on a .sln file it generates a .metaproj file based off of the "Project" section in the .sln file. It then executes aspnet_compiler.exe against the metaproj file.
I've worked with PHP but never C#, and I need to make 1 change to a file, and was hoping I could get some guidance, or suggested resources to learn more.
I have 1 cs controller file where I want to change the [Authorize(Roles="A")] to [Authorize(Roles="A,B")]
I made the change but nothing happens, so I've come to the conclusion that this cs file probably needs to be compiled.
The question is, is there a way to compile this one file? Or does the entire site need to be compiled?
When I open the cs files, it opens with "Visual Studio Tools For Application 2.0 2008".
Is this sufficient to make the changes?
My thinking is that one of the following needs to happen:
Scenario 1:
Open the .cs file in the appropriate compiler (of which I do not know
what it is) Compile it and copy the newly compiled file into the
appropriate folder.
Scenario 2:
Open the whole project in a compiler - of which I'm guessing the
".csproj" file to open. Compile the whole project Copy the desired
compiled file to replace the old file.
Scenario 2b:
Open the whole project in a compiler - of which I'm guessing the
".csproj" file to open. Compile the whole project Copy everything
back to the server.
Scenario 3:
The code I have is not sufficient to do the changes, and I need some
other source code.
That's all I've got, if someone can suggestion which one(s) may be on the right track, and how I may go about doing this, it would be greatly appreciated.
Thanks
The fact you are talking about a Controller would strongly suggest you are working on an ASP .NET MVC project. You will have a .sln file which is a solution file which is the master document if you will:
YourWebsiteSolution.sln
YourWebsiteProject.csproj
YourController.cs
Once you open the .sln file with Visual Studio (you need to know what version but you can get the latest here: Download VS2012 Web Express). You can the choose Build -> Build -> ReBuild Solution from the menu and that will re-compile all of your .cs and associated files into DLLs that will be in your \Solution\Project\bin\Debug folder (or Release depending on build).
When you deploy to the server you only deploy the .DLL files (in this instance). You NEVER deploy the actual .cs files as they contain the code and you don't want people peeking into them (this differs from PHP where the code is on the server).
Because you have not changed any of the views you don't need to follow this step but for a full deploy you would also copy any .cshtml or .aspx files and the usual suspects such as .css and .js etc to same folders on server as on the project.
I hope that is a good starter to get you going?
I have formed a number of source code files as my library. For example, I wrote LinqExtension.cs providing Median() function.
Now I'm working on a project which needs LinqExtension.cs. As usually, I link the file to the project. As introduced here. The reason that I link files rather than copying them is to keep the files at a single location. If I modify a file, all dependent projects get affected.
I also add the project to Subversion and upload to and download from Google Code. The linked file is not under version control.
I work on the project at home as well as at office. I hate copying the linked file to my office, which makes the file not single.
I figure out a solution that add <Compile Include="http://www.example.com/LinqExtension.cs"/> to csproj file so that the file only exists on the Internet. Once I upload a new verison of the file, all dependent projects get affected. Unfortunately the solution doesn't work.
Any other suggesions or better practice?
A better way would be to share your core library at the binary level, rather than at source code. You could set up a private Nuget repository to make this easier.
If it is absolutely necessary to share files, you can use pre-build actions in your project to copy the file from a common location, or even download them from google code. It's not clean, but if you don't want to use source control for it then I don't think you will find a clean way.
I like to keep a library folder of binaries in my Dropbox. That way Common libraries that I use can be accessed from my home and work project workspaces and the service keeps the version up to date.
Having created a WPF/C# demo application (in Visual C# Studio Express), what are the minimum files I would need to zip up, to give the source to someone? (Not deploy an executable, but enough actual source code to recreate the project).
Obviously I need the *.xaml *.cs *.sln *.csproj files.
Do I need *.suo *.csproj.user, or are those specific to my editor?
Do I need any or all of the files in the Properties directory? Some of those files say auto-generated, which would seem to imply they're not needed.
I'd share the Properties files as well, it generally being a good idea to share and version all files that are needed to compile the project regardless of the IDE. Since it's an IDE tool that generates those files, I'd consider it bad form to leave them out, in case you want to set up a Continuous Integration server or something of that sort.
The *.suo files are Solution User Options, which kind of implies that they're per-user, not per-project. Same goes for the *.user files.
the simplest thing is to delete any obj/bin directories (if they exist), and just zip up everything else.
the .user and .suo are things that will get recreated, but there's no harm in sending them (unless they are really big!)
That being said, it really depends on the details of your project, and how you have it organized.
I'm still learning the basics of how VS2010 sees the world. Apparently, you can optionally "include" a file in a project. I'm a bit confused by this: If a file is version-controlled, AND the file is within the project directory, shouldn't it implicitly be "included" in the project? If not, what's the use case where a version-controlled file in the project directory should NOT be included in the project?
=== Addition ===
Based on the answers I've gotten so far, maybe I should rephrased my question: What does it mean for a file to be "included" in a project?
A project needs to know about files in order for compilation and distribution to occur. Just because you have a file that's under source-control, doesn't mean that it will be compiled if the project is unaware of it.
Also, you may want to include files as part of a distribution package. We do this quite often for our web projects that we distribute using web app gallery.
Conversely, you could have documentation or sql scripts that you version control, but do not want them to be part of the project.
EDIT: In answer to your update, what it means for a file to be included in a project is that the file is actually added to the .csproj or .vbproj file and will be used during compilation and/or distribution. VS does differentiate if the file is Content or if it needs to Compile it. This can be seen by clicking on the file in Solution Explorer and looking at the Build Action property.
No, you don't want random files that happen to be in the project directory included in source control.
We do sometimes put documentation (pdfs) or drawings/schematics in the project folder and under version control but you don't need them inside the visual studio project (especially when they are not being distributed because they are for internal use only).
Excluding the file from your project can be useful if the file is related to the project but not necessarily needed in the solution.
Example
If I need some test XML for an application that i'm writing; that is designed to normally be pulling this from a WCF service, it can be useful to keep that file in the directory for a development environment where I use IO to get the XML for testing, but I don't necessarily want it in my solution which is source controlled.
When you exclude a file from a project is no longer compiled or embedded, then when you want to include it again you can do so without having lost your settings.
If you e.g. copy a file (containing a helpful class which want to have in your project) into a folder of your project, then you will see ... nothing. You have to check the option "Show all files" of the solution explorer and the copied file can be seen, but it is still "greyed out". No you can choose the menuitem Include in project and that file will be integrated in your project and a pending change (add) for your source control is added too. Visual Studio doesn't include all files it can find in the project folder automatically to the project - and that is a good feature.
One of my colleagues explained to me a scenario in which a version-controlled file should NOT be part of the project. Here's the idea:
A developer writes some new code.
The code is experimental, and not intended to be part of the normal build.
The easiest way to exclude the file from the build is to NOT include it in the project, but still version-control it.
This way, the file can be shared with other developers, but not break the build.