I want to use WCF RIA Services without need to install this. My idea is just to reference the libraries:
Microsoft.ServiceModel.DomainServices.Hosting.dll and Microsoft.ServiceModel.DomainServices.Tools.dll
in my Solution Libs folder.
This avoid overhead for devs and even for deployment.
This solution creates some evil hide monster? I forgetting something?
*I tried this and, well, "It works in my machine" until now.
If you reference DLL´s that are only on your development machine, make sure your reference doesn´t point to the Globsal Assembly Cache. Otherwise the other developers can´t find the reference.
Also selecting ´Copy Local´ for the references will make sure they are copied to the bin directory so you can deploy the solution with the necessary dll´s included.
I would suggest storing the actual dll files in a References folder in the root of your project. Then add them to your project through visual studio. Once you've done that add the hintpath node to the actual project file for each reference, which will tell VS where to look for the file. This method works great especially if you are working with multiple projects because then you dont have to copy the dll files to each bin directory.
Related
I must put this program into production today, and I can't get it to run independently.
In the program, I have included NuGet package "Imports ClosedXML.Excel" and use it to create spreadsheets. When I build my executable, and try to run it from another computer, it cannot find the ClosedXML and Documentformat.OpenXml assemblies.
I checked in References that "Copy Local" was = True for ClosedXML and Documentformat.OpenXml, but it's not working. I found another website that mentioned Global Assembly Cache, and that if the dependency is in there, it will not be included in the Build .exe.
I am running Visual Studio Professional 2017. I am in over my head on this one, so if you have answer (and I hope you do), please try to provide it in elementary terms I can understand.
Sometimes issue is solved by individually adding application files inside the following menu
Go to Publish-->Application Files
Select Show all files
Under Publish Status
Set the files you need to Include [not include(auto)]
That Webkit.Net project is great and working fine for me.
https://sourceforge.net/projects/webkitdotnet/
So how could I manage to exclude the dll and other files to separate subfolders? I was thinking about just putting the librarys into subfolder. But somehow I nowhere found a solution that works.
So how can I put the Wekbit.Net into the subfolder webkit.
Here some links I already looked through but not found a solution for vb and win forms:
How to save DLLs in a different folder when compiling in Visual Studio?
C# Putting the required DLLs somewhere other than the root of the output
Copy all files and folders using msbuild
NuGet issues with packages.config, project references and the solutionwide packages folder
http://www.visualmicro.com/page/User-Guide.aspx?doc=Add-Libraries.html
http://msdn.microsoft.com/en-us/library/ms181484.aspx
http://support.microsoft.com/kb/837908
If the Webkit assemblies are neither in the same directory as your application nor in the GAC, you have to tell your program where it can find them.
This answer explains how to resolve assemblies that couldn't been loaded by the CLR: https://stackoverflow.com/a/1373295
Ok, so I've got a somewhat complicated problem with my build environment that I'm trying to deal with.
I have a solution file that contains multiple C# projects which is built by a NAnt script calling MSBuild - passing MSBuild the name of the solution file and a path to copy the binaries to. This is because I want my automated build environment (CruiseControl.Net) to create a folder named after the revision of each build - this way I can easily go back to previous binaries for any reason.
So idealy I have a folder layout like this
c:\build\nightly\rev1
c:\build\nightly\rev2
c:\build\nightly\rev3
...
c:\build\nightly\rev10
etc.
The problem that's arisen is I recently added the latest version of the Unity IoC container to my project, checking it directly out of MS's online SVN repository. What's happening is I have a Silverlight 3 project that references the Silverlight version of Unity but I also have other projects (namely my Unit testing project) that reference the standard (non-Silverlight) version of Unity.
So what happens is since MSBuild is dumping everything into one single folder the Silverlight version of the Unity assembly is overwriting the non-Silverlight version because they have the exact same assembly file name.
Then when CruistControl runs my unit tests they fail because they don't have the proper dependencies available anymore (they try to load the Silverlight specific Unity assembly which obviously doesn't work).
So what I want to do is:
keep my desired output directory
structure (folder\revision)
I don't want to have to manually edit
every single proj file I have as this
is error prone when adding new
projects to the solution
Idealy I would like MSBuild to put everything into a folder structure similar to this:
nightly\revision1\project1
nightly\revision1\project2
nightly\revision1\project3
...
nightly\revision2\project1
nightly\revision2\project2
nightly\revision2\project3
etc
I can't modify the Unity project to give it a different file name because it comes from another SVN repository I cannot commit changes to. I found a similar question posted here and the suggested solution was to use a "master" MSBuild file that used a custom task to extract all the project file names out of the solution then loop over each one building them. I tried that but it doesn't build them in the order of their dependencies, so it fails for my project.
Help?
Firstly I would always have the build server delete the old working copy and check out a fresh copy to avoid any problems with stale artifacts from the previous build.
Next I would have nant or msbuild build the solutions as before with the artifacts from each build going to their local working output folders.
After that I'd move the artifacts from their working paths to their output paths, this shouldn't require digging through the project files since you can just tell msbuild/nant to copy working\project1\bin\release\**\*.* to artifacts\project1\.
The script that does this should ideally be stored along with the source with the main file, e.g. build.nant or build.proj in top level of the trunk.
For third party libraries I would simple include the DLLs directory in your repository. Nothing worse than writing some code and having a third party dependency break your build because of changes on their end.
Simply document the versions of the libraries you are using, and if you must update them, you'll have a better sense of what breaks the build before you even check it in.
Also, doesn't CC.Net automatically handle the providing of releases based on revision? I'm using TeamCity and it keeps a copy of the artifacts of every build.
I highly recommend reading JP Boodhoo's Automating Builds with NAnt blog series. That's been my starting point and have made lots of changes for my own taste. I also highly recommend checking out the builds of many open sources projects for examples. I've learned a lot from the builds of the Castle/Nhibernate/Rhino-Tools stack.
Often times a developer on my team will create a new Visual Studio project and reference a DLL somewhere on their local machine (e.g., C:\mydlls\homersimpson\test.dll). Then, when I get the project from the source control repository, I cannot build the project because I do not have the referenced dll in the exact same location on my machine.
What is the best practice for storing and referencing shared libraries?
I typically create a lib folder in my project, where I put the referenced dll's. Then I point the reference to the dll in the lib folder. This way, every developer can build the project after retrieving from source control.
If it's a project that was built in house, you could also add that project to your solution.
If the assembly is not in the GAC, create a directory called dependencies and add all assemblies there. The folder and the assemblies are added to source control. The rule is that given any project in source control, all that is required to build is to do a checkout and build the project (or run some tool that is also checked into the project).
If you add a folder to the solution and add the assemblies to the solution folder, this also provides a visual cue to the devs that indicates what external dependencies are present... all dependencies are in that directory. Relative paths ensure that Visual Studio can locate the references without a problem.
For large solutions, with 20+ projects, this makes life much easier!
Best practice I would expect would have Your SC repository include and enforce the relative locations of referenced objects for you (usually via a shared path), so you aren't dealing with this issue directly. The original developer should check in this information.
If you check in the actual DLLs into source control, then you can reference them by relative path and all developers will automatically get any dependencies when they next update the project.
Adding a DLL reference by full path would be a developer error just as adding a source file by full path would be an error.
Rule of thumb: If the project isn't a part of the solution, reference released dlls from a source controlled /binshare or /lib directory that is under your solution's source control tree. All external dependencies should have versioned DLLs that go in this /binshare directory.
I understand what your co-worker is doing in regards to convenience. However, that developer's approach is diametrically opposed to proper configuration/build management.
Example: If you use the MS Data Application Block as a dependency in your application, you should reference a properly released binary, instead of getting latest from MS's dev source trunk.
I think this approach is quite the opposite of what I would consider best practice. I think it would be a much better approach to keep the third party binaries out of the source repository and reference them through something like a Maven repository in your build process. Putting the dlls in the source repository unnecessarily bloats the contents of the repository and results in gets of projects taking considerably longer then necessary. It also makes the independent management of the third party binaries' versions obfuscated by not referencing the version by name but rather implied by referencing the dll of a particular version stored in the projects lib folder.
Why not set up a private NuGet-feed? This way, there is only a single copy of a dependency (the NuGet repository) and multiple projects can reference it. Multiple versions of the dependency can coexist, and each project can reference a different version, if necessary. Also, TFS Build can restore the packages at build time.
Configuring VS: https://www.visualstudio.com/en-us/docs/package/nuget/consume
WSPBuilder
Version: 0.9.8.0830
Created by Carsten Keutmann
GPL License 2007
Install and deploying [MYDLL]
Unable to deploy solution
Inner exception(1): This solution contains one or more assemblies targeted for the global assembly cache. You should use a strong name for any assembly that will be in the global assembly cache.
I had the same issues but what worked for me was to delete all the files in the bin and obj folder and then rebuild the WSP.
In my case, I was getting some strange errors (can't remember the exact message) when using Delay sign only option for one project.
I have found the problem, but not the solution, it seems the project I have which is really a 12 hive, is also set to output a class library, this class library is getting included in the WSP.
So... I need to ensure the bin folder is really excluded from the build process.
I set the value in program files but no reaction yet...
Now going to restart the server...
Later: Ok - the fix is to restart the server, for some reason this helped
I'm experiencing the same issue, one solution, multiple projects, the one failing to compile is using an object from another project.
I've tried clearing the bin & obj folder, as well as restarting the server. I think I'll copy the files dll to the gac using gacutil instead.