I have a C# solution being developed with MonoDevelop, there are a number of projects.
When the solution is being built, I need to make sure some project A is built after some other project B in the same solution.
I can add reference to project B into project A, that's called Project-To-Project reference. This approach does not fit my requirements as B's output gets copied into A's target folder. So, I can not use P2P reference.
According to this, http://monodevelop.com/Documentation/Solutions_and_Projects_explained, solution file (*.sln) supports "specifying build order".
Can anyone provide me with any info on how I can specify projects build order on the solution level, without using P2P references?
TIA
Related
I have a project that depends on another project, how can I configure Jenkins to use the reference of that project in the workspace.
For an example, project B depends on a certain set of classes from project A. Jenkins should be aware to build project A first and then B.
The trigger point is when a commit is pushed to the master of project B.
If a project depends upon another project, it is typically part of the same solution and always part of the same source tree. This means the slave will probably have the source already - or if it doesn't, the step that obtains the source needs the workspace mapping updated to not exclude it.
Also, when a project depends upon another project, the reference information includes the path to the referenced project. In the absence of solution file, this is used directly to build the other project with the same configuration (as in Debug/Release).
It's usually best to use a solution file instead of building projects directly as that ensures platform/configuration customisation is honoured as well as determining the correct build order of the projects.
So I got it sorted out. Since my project was based on project reference, the path had to be the same.
Naming the Jenkins project folder same as the dependent project name I referenced solved the issue.
I was under the impression that another workspace can't access another workspace. But it seems to be Jenkins handles it internally when building projects.
I'm checking for ways to add a reference to a project in another solution.
To be specific, I can add the reference to a project, even if it is in another solution. But I met 2 issues:
It refer the project by relative path, which may or may not exist if
my colleagues update the project
The Nuget package is not there (it is in the other solution's package folder)
For example, Let's say Project Restaurant (Solution A) depends on Project HotDog (Solution B). On project HotDog we refers a library Quartz for example.
But when we build, it would throw an exception "cannot find Quartz" because the reference of HotDog is pointing to "../packages", not "[Path_to_solutionB]\packages"
Of course we can re-add the reference but this solution is temporary only and will not work on our CI server (will retrieve these configurations through SVN).
I think there must be a way. So is there any best practice to cross-reference project in different solutions, without impacting the solution-managed Nuget Lib Packages?
I don't know if there's a way to achieve this, but I have a solution with its references on a single form page (made with ext.net, by the way) and wanted to use it as a reference to another project.
Is this possible?
Edit:
I think it was a poor question afterall. I have a solution with 3 different projects (web, entity and bals) and it's all good there. They all work together for a single form page. Now, I want all of that stuff to be inside another project, which is inside another solution, and call that page with its references from this other solution I'm trying to get it in.
To call an object (or a form) from your original solution in your new solution, you need to add references to Web, Entity and Bals.
There's 2 way to add a reference. You can add a reference to the compiled DLL / EXE or, if you have the source project, you can include the project in your solution (File -> Add -> Add Existing Project) and then add reference to that project.
If I understand your question, you would like to link an entire Solution instead of each projects individually. This can be done by changing the Add Existing Project filter from All Projects Files to Solution Files. This will allow you to import every project from the given .sln file.
However, this is a one shot deal operation that will import the projects at a given time. If you add or remove a project from your original solution after you linked them, you will have to do the same in your new solution.
When adding a reference to a project, you can select another project within the same solution or you can select a compiled DLL. If you have a library project in one solution and an application project in another solution then your only choice is to build the library project and then reference the compiled DLL in the application solution.
That said, there's nothing to stop you adding the same project to multiple solutions. You can add the library project to the same solution as the application project without removing it from its current solution and then you can work on it at the same time as the application, including debugging both at the same time. The application project can then reference the library project instead of the compiled DLL.
In all of my other .net apps my build process (a mixture of nant and custom tasks) automatically updates the [AssemblyVersionAttribute] AssemblyInfo.cs with the current build number before the call to msbuild, stamping in the build number in the version number.
I'm now working on my first BizTalk project and I'd like to do the same thing with the version numbers of the BizTalk assemblies, but I've run into trouble!
First of all the aseembly version numbers are stored in the btproj files, so I did some googling and found www.codeplex.com/biztalk which looked like the answer to my problem, but there is a deeper problem!
I have a project for my schemas and another for my pipelines, the pipelines project references my schemas project as I have a flat file dis/assemblers. The problem comes when I update the version numbers, as updating them even from within visual studio does not update the pipeline components references to the schemas.
So if I update all the version numbers manually in the VS IDE from 1.0.0.0 to 1.1.0.0, the build fails as the pipeline components flat file dis/assemblers still reference the old 1.0.0.0 version of the schemas! They don't automatically update!
Is this really a manual process of updating the version numbers of the BizTalk projects in the property pages, then building the projects and manually updating the references to them in the properties of all the pipeline components that reference them?
This means that I can't have my build process control the build number part of my version numbers!
Or is there a better method of managing the version numbers of the BizTalk assemblies?
I'm sorry to disappoint you but I've been down the exact some road I had to give up. I guess it could be possible to achieve it but it would require a lot of changes to both the binding files and other XML files (as you mentioned and even more if you have published services etc).
Maybe it could be possible to wrap all these necessary changes in a build step (a MSBuild step or similar in other build frameworks) - that would be useful!
Developer- :)
We had the similar problem and we ended up developing a small utility which would change the version number in all the projects i.e. *.csproj (asssemblyinfo.cs), *.btproj accordingly. Apart from this it would open and modify the *.btp files with the new version of schemas. In nutshell, what all you have to do is to configure this utility in your VS.net tools menu and execute it.
I guess its not very difficult to develop such utility in any .net lanagauge.
Caveat: Do not forget to save the files after updates with the same encoding as they were originally.
Cheers!
Gutted, thought that might be the case. Maybe BizTalk 2009 projects will play more nicely when updating references when changing version numbers.
I started to go through and automate it manually, and when I realised what needed to be done, I took a biiig step back when I realised just how many places I'd have to modify to get it working. Thank god for Undo Checkout.
I do have a standard C# class library included in my project (various helper functions), which i am able to update the version number of during my build process, so I'm basically using that one assembly to version the whole application. If anyone wants to know what version is in any environment, check out the version number of that one assembly.
Not ideal, but it's working.
We've done this successfully on our project - I'll see if I can get the developer of the tool to post details...
This problem arises when you perform an integration build to the latest versions of your dependent components as file references (aka schemas here).
Keep in mind that upgrading the assemblyversion must always performed manually, that way you are always in charge of changes to assemblyversions.
A possible solution to solve the buildbreaks issue is to file reference to a specific version of a dependent component build and not to the latest version and use a subst drive and a copy script to get the latest component builds.
For example:
SchemaA, assembly version 1.0.0.0
PipelineA (with pipelinecomponent XMLValidator for example), assembly version 1.0.0.0
PipelineA has a file reference to a subst drive(say R drive, which maps to a workspace D:\MyComponents) and version 1.0.0.0 of SchemaA as follows:
R:\SchemaA\1.0.0.0\SchemaA.dll.
The copy-script copies the buildoutput of SchemaA locally to your R drive.
When schema A updates to version 1.1.0.0 you don't have any issues because you still use version 1.0.0.0 and YOU have the choice to use the 1.1.0.0 version of your schema. When you want to upgrade, you have to alter your copy-script and replace the file reference to R:\SchemaA\1.1.0.0\SchemaA.dll.
Let's say you have a solution with two website projects, Website A and Website B. Now inside Website A's App_Code folder, there is a Class X defined in a ClassX.cs file. What do you do if Website B also needs access to ClassX.cs?
Is there any way to share this file across App_Code folders? Assume that moving the file to a common library is out of the question.
Please please don't use these unholy website projects. Use Web Application projects instead, pack your shared classes into a library project and reference it from all your Web Applications.
Pack your shared classes into a Library (a DLL) and from each site right-click on add reference and select the library that you have created.
With the restriction of "Assume that moving the file to a common library is out of the question." the only way you could do this is to use NTFS junction points to essentially create a symlink to have the same .cs file in both folders.
This is a terrible option though (for versioning reasons)...moving it to a common library is the best option.
Here's the Wikipedia entry on NTFS junction points
http://en.wikipedia.org/wiki/NTFS_junction_point
and here's a tool for creating them
http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx
I don't believe that there is a way without moving ClassX into a new code library project. .NET requires all an assembly's dependencies to exist in the same folder as the assembly itself, or in the GAC, to be automatically detected.
You could try loading the assembly manually via the Reflection classes, although it's a bit hacky.
The best solution, if you have the time available and the inclination to undertake it, would be to go with JRoppert's solution of moving it to a web application project. You could then use web references (which work about as nicely as regular references inside VS) to refer to ClassX.
HTH