I have a .net mvc site that should be published to a lot of different customers, and thus vary slightly depending on the target.
Is there any way to set up the core project structure, e.g. (simplified):
views
models
controllers
assets
bin
and make a merge at build time with whatever variations the current target might have. For example:
core project:
views
view1.cshtml
view2.cshtml
(removed rest of the folders for brevity)
customer 1 target:
views
view2.cshtml
view3.cshtml
desired merge result:
views
view1.cshtml (from core project)
view2.cshtml (from customer 1 target)
view3.cshtml (from customer 1 target)
The same rule should apply to controllers, binaries etc.
I would either use multiple projects, nuget, or use source control. I will talk about these ideas below, but in no particular order. By the end I may include a preference towards one or the other.
First idea I'll talk about is to use multiple projects. Create your base project, let's call it WebBase. Create your core website that you have talked about. Next create Customer1 website, if you create Customer1 as an empty website you will need to recreate the folder structures in WebBase or you cane create it the same as you did with WebBase and remove all the files(do this from within Visual Studio); either way you end up with the folder structure with no files. I would recommend keeping web.config,packages.config, Properties folder with AssemblyInfo.cs. Then you will add the files from WebBase, but don't just add them normally. For illustration's purpose let's do the Home Index View: Expand the Views Folder in Customer1, Right click on home, choose add, choose Exising Item, browse out of Customer1 and then in to WebBase/Views/Home and single click index.cshtml, now notice the drop down on the button? click that and choose "Add as Link". Now do this for all the files in WebBase! It will seem cumbersome to choose "add as link" every time, but if you just click add, it will copy the file and updates won't propagate from WebBase to Customer1! Also, you will see things like remove from project vs delete (with prompt about permanent deletion).
Second thought would be to create a nuget package for WebBase and you can than install it as a package, the benefit of this approach would be versioning and it would not require you to update every project with each little change. It would keep each project completely isolated. Down side is you would need to update each project individually to propagate changes globally. You would need to learn about nuget's nuspec file and how to include files and such. It isn't that bad, it is just XML. But you can indicate which files to include when the package is installed/updated.
Third would be source control, I know with git you can use submodule to include a seperate project (even from external repository). Which might be an option, or you could just create a WebBase branch, setup WebBase and then branch it off into each Customer's website. So create a branch called Customer1, start adding the custom customer things. Switch back to WebBase, create a new branch called Customer2... you are off to the races. Switch back to WebBase, make a global change and then merge these changes into Customer1 and Customer2 branches.
Okay, I will admit it, I would probably go with the third option. It gives you lots of benefit with little downside. It even get gives you history! If you aren't currently using source control... you should! You can install git on your machine and have the ability to check code in locally and you don't have to worry about an external repository (although I would recommend you have one as it gives you DR).
Either way, there are options available. But nothing like a single project with configurable file includes.
Good luck!
First thing that comes in mind (and probably easiest because it does not require any additional tooling) is to create core project with core functionality, views and controllers. And for each customer create separate project with custom views and controllers. Then for customer-specific project simply link all required files from core project. It can be a little tedious to link the files depending on the number, but seems doable.
Another approach could be to use tools like CAKE or FAKE, with the help of which you can script the entire build process the way you want, but I never tried doing such custom scripting myself.
Third option that I can work as well is to conditionally include files based on defined constant, but that will require editing *.csproj files. The code can be something like:
<Content Include="Views\View1.cshtml" />
<Content Include="Views\View2.cshtml" Condition="$(DefineConstants.Contains('CORE'))" />
<Content Include="Views\View2.cshtml" Condition="$(DefineConstants.Contains('CUSTOMER1'))" />
<Content Include="Views\View3.cshtml" Condition="$(DefineConstants.Contains('CORE'))" />
<Content Include="Views\View3.cshtml" Condition="$(DefineConstants.Contains('CUSTOMER1'))" />
Not sure how easy it will be to maintain it though.
I would probably consider to split the application into independent components/projects that will contain all functionality related to the component. The during the build compose components with FAKE based on what components are needed for particular client.
Your requirement is a great candidate for a custom Visual Studio Project Template.
I am thinking of preparing one big project with all the features you're deploying to whatever customer. This project also could be the trunk that you might update when a new feature or a fix is needed. Then, export the trunk-solution into a template. Then continue with VSIX project template and incorporate a wizard into it, to collect user input on a project creation. Based on the input take the appropriate action and add/remove the necessary files or enable/disable features as needed.
Or you might just keep the source files on the file system and organize them into the template on the fly - i.e., as a result of the user input during the wizard. At the end of the wizard, the template is deployed and ... voila.
What you need is super-admin section, where you could [de]activate different portions of the site, depending on customer.
There are some really good code answers here but if you're wanting an Automated Build system for every client and you have loads they could be a pain too setup.
When you could set up a script for Powershell that can do this
pseudo code
For each client site
download base code to code/
download this client's changes to code/ overwriting files
msbuild ....
copy client/ bin to build/client/
Delete code/
End For each
The answer to this question requires some innovation. So look at my solution please:
Set up the core project structure for the classes that cover Model and Controller files and then use them with technique named Add Existing Item As a Link which can share the followings:
App logic common to both apps, but not portable
User controls with no platform dependencies
Unfortunately that is not supported for razor views. So the easiest thing to copy shared views is to have multiple layout files like famous _Layout.cshtml file, one in each web app. You can also Compile your asp.net mvc Razor views into a separate dll to use them like a Reference (as shared views).
For the Assets, You can host all your style sheets (and some javascript if appropriate) from your main web application and access it from each web app.
The bin folder has core MVC dll files plus those that you add for using in your project and a projectName.dll file which will be created after building. You can simply Add/remove them by right clicking on References using Add Reference tool.
Related
Let's say I have a c# project Foo and a classlibrary called Bar
I'm wanting to develop Bar alongside Foo which will use Bar as a shared library. I'd like to keep these Foo and Bar in their own git repositories.
When I debug Foo, I'd like to be able to step into Bar to see what it's doing under the hood. When I make changes to Bar, I'd like to be able to have my changes reflected in Foo. It's okay if I'd have to build Bar first for my changes to take effect.
When I eventually deploy Foo, I'd like to import Bar as a nuget package, rather than including it as a part of the solution for Foo
Is this possible in c#? I've been trying to develop a shared library and a repository that uses that library as a template for future projects. I've tried to publish Bar as a nuget package to my local filesystem but it's been giving me problems; I'm unable to step into functions that call into Bar from project Foo and when I make changes to Bar I have to build, pack, then publish the library again. If I don't bump the version number of bar when I do this, this results in errors where I have to go to the nuget package in my filesystem and delete it manually.
Aside
If you're interested Bar contains extension methods for setting up a connection to a message broker along with classes for configuration definition and "contract" classes that need to be shared among projects.
This is a common problem when developing code in nuget dependency chains.
One solution is to use something like NuGetReferenceSwitcher.
The disadvantage is that the tool will change your csproj files back and forth and you need to take good care of not commiting unwanted changes.
Another solution I employ successfully is to create a sibling project to your Foo project that uses ProjectReference to Bar instead of PackageReference.
I detailed the approach on my blog.
It involves editing your project files by hand, which is simple in SDK-style projects.
If you are comfortable with (or want to learn) that, here is the Gist:
Extract everything except the PackageReference to Bar from the Foo project into a Foo.props file.
Import that Foo.props file into the Foo project. Note that until now, effectively nothing has changed.
Create a copy of the Foo.csproj in some other folder and name it e. g. FooDev.csproj. Link the source files from the Foo (sic!) project into the FooDev project (using the technique that ΩmegaMan already described in their answer). Include FooDev.csproj in your Foo solution.
In your FooDev.cproj change the PackageReference to Bar to a ProjectReference.
You now have both a Foo.csproj that uses a PackageReference to Bar and a FooDev.csproj that uses a ProjectReference to Bar.
You will be able to immediately see the effects of the changes you make to Bar on the FooDev project.
you can go red path or blue.
"Is this possible in c#?" - This is not c# or any language. This is solution/project management. Many things are possible. You can definitely develop as raw projects or DLL. Include debug-built DLL and PDB file into your nuget, and you will be able to step through your referenced library.
You don't have to use a separate solution from yout GIT/TFS. You can develop using any local solution, not binded to source control.
I'm wanting to develop Bar alongside Foo which will use Bar as a shared library. I'd like to keep these Foo and Bar in their own git repositories.
Yes. In Foo, add all files from Bar as needed by add as Link. Namespaces and files will be honored as if they existed in Foo; but no files will be copied...only referenced.
This is an old Silverlight trick to share one set of code between two projects because of the two different versions of the CLR from the web services to the Silverlight project. It allowed models to be brought over from the web services without trying to pull in a dll which had a totally different CLR.
Create the code in project 1. Then for project 2, add the files by linking them from project 1. To do that type of add, its really adding a symbolic link to the file(s).
How
The trick is to include as a link into the project as needed.
In the second project right click and select Add then Existing Item... or shift alt A.
Browse to the location of the file(s) found in the first project and select the file(s).
Once the file(s) have been selected, then on the Add button select the drop down arrow.
Select Add as link to add the common files(s) as a link into the project.
I'm unable to step into functions that call into Bar from project Foo and when I make changes to Bar I have to build, pack, then publish the library again.
The linking of files, as mentioned, will gain access to the file as if the file was actually within the project, but the file physically resides elsewhere. If the linked file(s) change, those changes are reflected in the project that linked them in. Building due to changes still applies, but that should be minor.
I can't try this out right now, but I believe this is what we used to do (several jobs ago).
Create a project/solution for Bar, deploying it to a local NuGet package source. Add it to its own Git repo.
Create a project/solution for Foo, dependent on Bar via Nuget. Put it in a separate repo.
Create a FooPlusBar solution in the same folder (and repo) as Foo.sln. Start with an empty solution. Then add the Foo project and them the Bar project. If you are careful to keep changes to Bar updated in the NuGet package, I'm pretty sure you can get the debugger to recognize the Bar sources when you are debugging Foo from within the FooPlusBar solution. Yes, a single project can be part of more than one solution
Again, I think should mostly just work (no guarantees, though). I don't remember if you need to update the version number of the Bar package every time you make a change
I am trying to understand how I should structure my TFS/VSTS Folders and local workspaces/folders/mappings, etc. I am looking for a best practice approach I can follow along.
Currently I have got two projects within my VSTS account:
$/ProjectA
+- Main
+- ProjectA
+- ProjectA
+- ProjectA.sln
$/ProjectB
+- Main
+- ProjectB
+- ProjectB.sln
As suggested by this MSDN link I have created a 'main' folder at the root of the project. So I am able to create branches in case it is needed later.
Please note that ProjectA has an additional folder called ProjectA, which was created by Visual Studio, when using the new project wizard and checked "Add to source control".
Regarding ProjectB: First I have created the solution without adding it to source control. But then later moved the solution into the folder that is locally mapped. And afterwards opened the solution and choose "Add solution to source control".
I have got one workspace, called: "MyWorkspace". The path mappings within this workspace are set as follows:
$/ProjectA ==> C:\Dev\Projects\ProjectA
$/ProjectB ==> C:\Dev\Projects\ProjectB
NB: Both projects have nothing to do with each other.
Questions:
How should I structure my folders within the VSTS project? At which level should the .sln file reside?
How should I structure my local folders and the mappings?
Should I use one workspace containing all project-mappings or one workspace per project? Or should I even have multiple workspaces per project as suggested by some blogs? (sorry cant find the link anymore)
I agree with Flater, This question is completely subjective.
However MSDN provided the suggestions on using the server-side structure and client-side structure, also Branched Folders and Workspaces explained.
Strategies for Solution and Project Structure
The three most common strategies used to structure solution and
project files are:
Single solution. If you work on a small system, create a single solution and place all of your projects within it.
Partitioned solution. If you work on a large system, use multiple solutions to group related projects together. Create solutions to
logically group subsets of projects that a developer would be most
likely to modify as a set, and then create one master solution to
contain all of your projects. This approach reduces the amount of
data that needs to be pulled from source control when you only need
to work on specific projects.
Multiple solutions. If you are working on a very large system that requires dozens of projects or more, use multiple solutions to work
on sub-systems but for dependency mapping and performance reasons do
not create a master solution that contains all projects.
In general you should:
Use a single solution strategy unless the resulting solution is too large to load into Visual Studio.
Use multiple solutions to create specific views on sub-systems of your application.
Use multiple solutions to reduce the time it takes to load a solution and to reduce build time for developers.
Please refer to below links for details:
Strategies for Solution and Project Structure
Structuring Projects and Solutions in Team Foundation Source
Control
In some cases, you can create multiple workspaces to isolate and switch among the changes you are making in different branches.
If you’re using local workspaces, then you can see some performance benefits by switching to using “one branch == one workspace”. Please refer to phkelley's blog for details:
TFS Version ControlUsing multiple workspaces with Visual Studio
You can also reference jessehouwing's answer on how to use the workspace: https://stackoverflow.com/a/48355207/7466674
I hope it's not a duplicated question since I searched enough about it but I found nothing, maybe that's because I didn't know the appropriate words describing my situation.
The question:
Summary: Can Visual Studio build different editions of an ASP.Net Webform just by a simple wizard or something like that? Some Cs, Js Or Css files or some folders shouldn't be involved in the final output.
Detailed:
We have had a very large ASP.Net project containing lots of folders and involving lots of features, we have been offering the whole project to customers and we have been protecting it by License approach (which applies Private and Public keys mechanism).
Now the company considers to offer different editions of the application based on the customer type, so if the customer is a small business it will be offered an application with less features since he is going to pay less money.
Keep in mind that we don't want to offer customers the complete application and then based on the permission which are defined in a table in the database he can get access to just the features we tend, It's no that good, beacuse after he are given the limited edition license, he is able to change his permission by modifying the related table in databadse or if he dissemble the related Cs or dll files (I have read about obfuscation to make it safer)
They wouldn't gain anything even if they grant required permissions complately to themselves beacuse they don't have required files.
I had hared of an application which is used to manage -or better to say customize- the project build process, what is the best solution? would you enlighten me?
I would highly recomend you to look into build configurations in visual studio. There you can choose what project files to build and control the output.
Check out the following for more details:
https://msdn.microsoft.com/en-us/library/kkz9kefa.aspx
I'm still looking for the best solution but for now, after searching a lot I found some solutions applying MsBuild, for instance to exclude some folders and some files from being published you can add following script in visual studio project file (.csproj):
<ItemGroup>
<ExcludeFromPackageFolders Include="Scripts\large">
<FromTarget>Project</FromTarget>
</ExcludeFromPackageFolders>
<ExcludeFromPackageFiles Include="Scripts\mash.js.chirp.config"/>
<ExcludeFromPackageFiles Include="Content\mash.js.chirp.config"/>
</ItemGroup>
This will cause the following folder and files to be excluded:
Scripts\large
mash.js.chirp.config
You should add above script in .csproj xml config file exactly below the line which says:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
Here's some useful links: This one and This one
Keep in mind that there is no visual studio project file in Web site so you can apply it in Web application but Website, Here is the source from MSDN.
Although here it's told that you can use MSBuild even if it's about Website, Take a look at this link so you'll learn how to create a project file for that purpose.
It's dead simple to share functionality across multiple MVC projects. You just put the code into its own project and reference it in as many solutions as your heart desires. Clean, standard, glorious.
Is there any means to do this for styling code? I'd like to have our common CSS files, the ones that give our applications a similar look and feel, in just one place. Right now I have to spawn new copies for every new application. Thus if something needs to be fixed, it needs to be fixed a dozen times in a dozen places.
Has anyone else dealt with this? I can't separate out the CSS files into their own project, nor do I really want to have a web application that's just css sitting somewhere so all of the applications can use the files remotely via fully-qualified Urls. Is there a TFS trick you can do with source control to link the files together? Is there something I haven't thought of?
Here is the "dead simple" solution for sharing web resources between projects without using CDN, LESS, SASS, NuGet, etc:
Create common Solution Folders containing the resources to be shared, or simply designate one of the projects to be the master.
Use "Add as Link" to add the shared resource files to each project as needed.
Add an AfterBuild task to each project file that will copy the linked files to project folders. This is only needed so that Visual Studio test/debug (F5) will work locally.
If you need the details on how to do this, keep reading.
Configuring Solution Folders for the Shared Resources
** Note that if you're simply going to share files directly from one project to one or more additional projects then you can skip this step.
Visual Studio solution folders do not have to reflect physical file system folders, but doing so will help preserve your sanity. So first create the folders on your local file system and copy the resource files into them. The new folders should be located under your solution folder. For example:
\MySolution
\Common
\Images
\Scripts
\Styles
Back in Visual Studio, right click on the Solution Items folder and use Add Solution Folder to replicate the new file system folders.
Next, add the files to the new solution folders by right-clicking each folder and using Add Existing Item to add the contents of the folders.
Add Shared Resources as Links
For each project that will use the shared resources, right-click the project folder and choose Add Existing Item. Browse to the common folder, select the desired files, click the drop-down arrow next to the "Add" button and choose "Add as Link".
You may get a source control warning about adding files that are outside of the project directory structure, but this can be ignored since the linked file will be under source control at its source.
Add an AfterBuild Task to Copy Files
When you publish the application to a server the linked files will copied to the project folders to which they are linked and everything works as expected. However, in the development environment the linked files do not physically reside in the project folders. So when you hit F5 to test your application in VS, the shared resources will be missing.
The simple solution is to add an MSBuild task to copy the linked files from their source after each build. This needs to be done to for each project that contains the shared resource links.
Right-click the project and choose Unload Project. Right-click the project again and choose Edit <ProjectFileName>. Scroll to the bottom and add the following (just above "</Project>"):
<Target Name="AfterBuild">
<!-- Copy linked content files to local folders so that they are available in the debugger.
This is only an issue when running the application locally. The linked files should
be automatically published to the correct folder when publishing to a web server. -->
<Copy SourceFiles="%(Content.Identity)"
DestinationFiles="%(Content.Link)"
SkipUnchangedFiles='true'
OverwriteReadOnlyFiles='true'
Condition="'%(Content.Link)' != ''" />
</Target>
** Copy task adapted from this link in TheCodeDestroyer's answer.
Save the project file then right-click and choose Reload Project.
Why not just have one site host that base styling and the other sites reference those styles? I don't see anything wrong with this.
You could create a CDN application of sorts to do this, too.
MVC App #1
<link src="~/css/styles.css" />
MVC App #2
<link src="http://mvcapp1.com/css/styles.css" />
Well, I don't know much about asp.net development, so forgive me, if it's not the case, but
If resource files in your project have Build Action set to None or Content and Copy to Output Directory set to Copy..., you can easily create the Class Library type of project and place all the files there (preserving the paths), and then reference this "Class Library" in every project that needs the files. Every file will be copied to every referencing project on solution build.
For Embedded Resource build action it will also work, but, you'll need to find a way to specify the assembly, which contains these files (because it will differ from Assembly.GetEntryAssembly).
Personally I don't like or want the CDN solution as if you have many pages they depend on CDNs 100% up time. After some research I found this solution which was perfect for my use I hope whoever will look for an alternative this is one of them:
http://mattperdeck.com/post/Copying-linked-content-files-at-each-build-using-MSBuild.aspx
1 - Look into CSS template systems as mentioned :
SASS-Lang
Less
http://css-tricks.com/sass-vs-less/ (really good article to start, many related items to in his related posts widget)
These allow you to code your stylesheets in organised manners. You can quickly add dynamic configurations and global changes easily.
2 - Developer your own CSS global listing system :
If you prefer not to use the above CSS stylesheet system. Example
//cdn.com/assets/css/reset.css
//cdn.com/assets/css/main.css
//cdn.com/assets/css/page_home.css
//cdn.com/assets/css/page_cart.css
even...
//cdn.com/assets/global/form_styles.css
//cdn.com/assets/global/global_shortcuts.css
In these, the same form padding, table and tr and other padding rules. Example
.black{color:#000 !important}
.right{float:right}
.left{float:left}
I know I sound like framework mentality but it works..
You can quickly alter the global to ensure all pages are updated.
The CDN storage and compass suggestions are valid too. You see storing on a CDN will save the headache of worrying about application failure / speed / load.
Your application can simply be like
/cloud/servers/settings/global/db
/cloud/servers/settings/global/librarys
/cloud/servers/settings/global/css_config.php (example)
/cloud/servers/1/webapp.com/
/cloud/servers/1/webapp.com/model
/cloud/servers/1/webapp.com/view
/cloud/servers/1/webapp.com/view/themes/tpl
/cloud/servers/1/webapp.com/inc
/cloud/servers/1/webapp2.com/
/cloud/servers/1/webapp2.com/model
/cloud/servers/1/webapp2.com/view
/cloud/servers/1/webapp2.com/view/themes/tpl
/cloud/servers/1/webapp2.com/inc
//cdn.com/assets/css
3 - Configuration of Approach
I personally think that the question should be about the approach of your overall development methodology. Having CSS sit on a CDN application, or having a CSS on a separate server which syncs to the CDN for production live mode is a good idea - keeping it separate and maintaining it via a stylesheet language is even better. You can then quickly use skins, css libraries, image libraries and more. Keeps things organised, faster and much better and ENJOYABLE to look at and take pride in coding with.
Keeping it and using a better system is what is needed. You should use manual and the classical approach of a folder structure IMO. You won't have to worry about responsive application design for mobile/tablet and other bearing issues with updating one CSS line for all the apps or even single apps - even languages, and dealing with multi site development teams.
JUST MY HUMBLE OPINION
Would also strongly recommend a CSS stylesheet language, sure many people hate them. But they are becoming quite useful, especially SAAS it's not a hype like NodeJS was.. it actually works. And does wonders. Look at TopShop, GorgeousCouture.. Arcadia sites.. multiple languages, multiple currencies.. servers and teams working on the same cross brand and several applications for each store..
We had the same problem and for our purposes we put all general CSS/JS/Images/Layout View into NuGet package and reuse it from every application where we need it. It perfectly works for us.
If you're open to using Sass, Compass extensions might be just what you need.
http://compass-style.org/help/tutorials/extensions/
An extension, when bundled as a gem, allows you to easily include the styles contained within the gem from anywhere on the system that has the gem installed. I recently used this in my latest application (a specialized multi-user CMS where each user has their own subdomain that has a customized layout, but all of the components/widgets have the same styling throughout the application). Setting up a new subdomain's styling is as simple as running a single command and customizing the template I've setup that has a skeleton of a simple layout.
Compass extensions can be used to hold images and JavaScript files as part of a template, but deployed files aren't automatically updated like the styles are (templates from a Compass extension differ from the stylesheets, as the templates are for copying and the stylesheets are for importing).
How can I have code-sharing between two projects without making a dll?
The issue is: I have a tool that syncs users & groups from LDAP to a database.
Now the tool is a windows service, but testing it as such is very difficult and time consuming.
Which is why I made a console application where I can test the LDAP syncing, and then just copy the respective sourcecode-files over to the service project.
But... keeping the common files in sync is a bit of a problem.
I don't want to make a dll, because this probably creates me a problem with
the 3rd project, a windows installer (for the service) where I have to use ExecutingAssembly path...
Is there a way to share the code without making a separate dll?
Automagic statical linking, so to say ?
How about adding a file as a link.
In Visual Studio right click on your console test app project -> select add existing file -> in the file add dialog navigate to files in your actual windows service project -> select the files you want to share -> and on add button select add as link option.
You can add a file to a project as a link. On the Add Existing Item dialogue the Add button has a drop down on its right. Use this to select "Add as Link":
Put the file as a solution item and add as a link to each project.
How about hand-modify the project files to point to the same source file?
Another option - put both projects in the same folder. Add a class to one, then in the other project add existing class and point to the class just created.
You could:
maintain the shared code in a separate project that produces a DLL and then use a tool such as ILMerge to turn the DLL & EXE into one assembly.
share the source-files between multiple projects, either by tweakiing your project files or doing something funky with your source-tree layout.
All that said, the best approach would be to bite the bullet and store the shared code in a shared assembly (DLL). What happens when you decide to, for example, expose this code via a WCF service? It starts getting more complicated then as you have 3 places that reference the same code files. Don't just think about what makes your life easiest now, think about what'll make your life (and that of anyone else who has to maintain the code) easier in the future as well! =)
Necromancing - As per Visual Studio 2017:
You can create a shared project, and then reference the shared project in another project.
It will use the framework-version and libraries from the project you reference the shared-project from. You can also use the same shared project in multiple projects, provided you get no conflict.
This is basically statical linking on a source-code level.
This also works with HTML&JavaScript-files (specifically, it works with publishing), but with HTML & JS files, you will run into problems while debugging...
It's under "Classical Windows Desktop", but you can also use it for .NET Core etc.
If you want to share functionality, you should use a DLL or similar.
Since what you want to share is the source, what you are essentially sharing is file sharing. So you can do that by making your projects reference external sources or you can have your source control do this for you.
If you are using Visual SourceSafe, you can make a link between two folders. VSS will make sure that they are treated as the same file.
I'm going to describe the setup we use to manage and test our Windows Service projects. While this doesn't answer the question of "sharing code without a DLL" (Unmesh's answer takes care of that), I think the OP probably doesn't realize how easy this is with a DLL. In any case, I'm hoping it will help someone.
Create a solution, LDAPSync. Create three projects in this solution:
LDAPSyncLib
LDAPSyncSvc
LDAPSyncTest
LDAPSyncLib is a DLL project that contains all of your business logic and main functionality.
LDAPSyncSvc is a Windows Service project that contains two classes, a service controller class that inherits from ServiceBase, and an Installer class for your service. This project has a "project reference" to LDAPSyncLib.
LDAPSyncTest is either a GUI application (WinForms, WCF, etc.) or a console application, depending on your needs. This project also has a "project reference" to LDAPSyncLib. Its sole purpose is to provide some interface which allows you to easily make the required calls into your business logic for testing purposes. In Visual Studio, set this as your "StartUp Project".
Now, when you run in debug via Visual Studio you will get a nice little GUI or command window that you can use to manually make test calls. When you install it as a Windows Service, the LDAPSyncSvc project's controller class will take over and handle all of the necessary service requests (start, stop, pause, etc.)
We have around 30 in-house Windows Service projects that we've been continuously managing, developing and testing for over a decade and this workflow has proved invaluable in quickly finding and fixing bugs when they arise. Best of luck with your project and I hope this helps some future Googlers.