My solution file contains a website project and some library projects. My website project is depending on these library projects and some other nuget packages. I have to build my .sln by MS Build. By executing nuget.exe all dependencies are loaded, but their references not updated to packages folder. When I google my problem I found the following solution.
https://www.codeproject.com/Articles/823752/ASP-NET-Website-Project-External-Assembly-Referenc.
But it did not solve my problem as I do not want to keep bin folder and I also do not want to keep the .refresh files of all the DLL. I need to load all external dependencies and referenced automatically, when I build .sln file.
ASP.NET website update assemblies references without modifying .refresh file
If I understand you correct, you can add a class library project to the solution, and add reference to the class library project to your website. Then, add the nuget in the class library, not the website project.
Then you could use nuget.exe update those nuget packages for the solution, like:
nuget.exe update "<YourWebsitePath>\WebSite1.sln"
In this way, When your build website, it pulls in all the class libraries' dependencies in turn.
If I am not understand you correct, please let me know for free and you can share a simple sample about your question, so that we could understand it more clearly.
Hope this helps.
Related
I'm working on an ASP.NET MVC 5 project that was initially using Nuget for static content like Bootstrap, jQuery etc. I have now switched to bower as it is the way to go and is also integrated with visual studio.
I noticed that when installing bower packages, they are not automatically included into the project. So I have left them out for now but is this a good idea? Should bower packages be included or not? It doesn't make any difference to access because in my BundleConfig.cs file I'm still able to link these files to aliases as before.
bower will download the entire package using Git.
Your package must be publically available at a Git endpoint (e.g., GitHub). Remember to push your Git tags!
This means that bower will actually download the entire repository/release for you to use in your ASP project. I've tested this with bootstrap and jQuery. These repositories can contain many many files so including them into the .csproj file will clutter your project file and may not be ideal.
This can be compared to using nuget packages where we are only referencing external packages in the packages.config file but we do not include the dll and other assemblies into the project. This leads me to think that bower_components should indeed not be included in the project; this makes no difference to usage as you can still reference the packages and use the files.
About: I have a ASP.NET website (not Web project) with 3 class library projects in the solution. Earlier I was using SVN but now Git is used source management. I have installed the git locally on a computer (used as server) and using it for merging the source code from other developers. Also, I am using Visual studio 2015 community edition which provides the tools to work with git.
Problem: After cloning the project from the master repository, I build the project to run it. Building the project shows a dialog box saying "Package Restore is in progress". This process creates a folder named "Packages" and that folder includes every package listed in the packages.config file. But after restoration completes, the project throws the following exception:
This exception shows for each package (Autofac here).
The type or namespace name 'Autofac' could not be found (are you missing a using directive or an assembly reference?)
Work around To Solve this problem, I need to uninstall each package and installed it again and problem is solved. This thing I need to do again and again for each developer machine, which is frustrating and time consuming too.
Does anyone has faced the same problem working with Nuget, git and website in ASP.NET.
I faced a problem like this before. In my case, the reason was that I changed the project path (moved the project to another directory), and the path of the packages directory (that contains the NuGet packages) was stored in the csproj file for the old path, that is VS cannot restore NuGet packages. The solution for this was to edit the csproj manually and make it referring to the correct new packages path.
If this doesn't work for you, you can still use your workaround, but using the following PowerShell command (in NuGet Console) for simplicity:
Update-Package -reinstall -Project Your.Project.Name
Note: project name doesn't contain csproj extension, just the project name
It is good practice to not put third party packages into source control. It bloats your repository (even on a large web application, the size of the external packages will massively out weigh your code).
If NuGet package restore is slow, you could look at using a local cache (this can be as simple as a shared folder) or a better internet connection.
That said, you should only have this problem once per machine. While the packages are downloading you could be giving the new team member an overview of the design…
Make sure that all of your projects are using the same target framework, when this isn't done you can often get the
type or namespace [name] could not be found
warning.
To do this, right click each of the projects in the solution explorer > Properties > Application tab > Target Framework. They should all be the same or there will be incompatibilities between the references in your projects. Here's a question regarding this, hopefully this helps.
The main reason is there no Autofac reference in packages.config file.
When you see on the screen Restore packages message box this mean that nuget package manager is trying to install all the packages which are missing in the package folder.
Try to do this step:
In Visual Studio Solution Explorer pick the project and via context menu pick Unload project
After project was unloaded via context menu pick Edit your project
Go to section group and find you Autofac Reference section
If HintPath doesnt looks like ..\packages\Autofac.4.1.1\lib\net45\Autofac.dll (Actual for 4.1.1 version) remove the Autofac reference Item
Save csproj file and reload project
Install Autofac via NuGet Package manager
Commit and push changes to git repository
Had the same problem with VS 2019. In ASP.NET, packages are updated via the .refresh files that appear in your bin folders. If these aren't checked into Git, they wouldn't be copied down to your cloned repro.
I added the .refresh files for all of my package dlls, made sure the versions and paths in the .refresh files were correct, and now everything updates as expected.
I created a new asp.net project, and I am using the monodevelop as the ide.
On the left hand side in the explorer I can see two sections, one is called reference and the other called packages.
I assume that references are the library or dependency files like the jar equivalent of java. Then what are the packages section for?
Is it also another kind of dependency?
Can anybody help me understand the meaning of those two sections?
I assume you mean References and Packages. There is no Resources section/folder when I create an ASP.NET project in MonoDevelop.
The References folder will show the assemblies that are being referenced by your project. An assembly is equivalent to a jar file.
The Packages folder shows you the NuGet packages that are being used by your project. A NuGet package will typically provide assemblies and these will be shown inside the References folder but within a From Packages folder. A NuGet package may include other things, such as content files, which are added to the project, or custom MSBuild targets which modify the build behaviour.
I noticed today that whenever I build a word add in project of mine, Microsoft.Sharepoint.dll is being copied into the bin folder and is subsequently included when publishing.
Is there an easy way to see why this (annoyingly large) dll is being included when publishing?
It isn't referenced directly. There are 3 dependencies in the project page and I've checked all these projects and none of them reference it directly either. Do I need to continue following the dependencies of those projects too?
Is there not some kind of log file for a build that could give me a hint?
EDIT:
The problem was that my project referenced a project that referenced a project that had a reference to Microsoft.SharePoint.dll with copy local set to true. I had to delete the dlls from all projects and rebuild with copy local set to false. I didnt realise that the 3rd party dll would be copied into my project.
If this is being pulled in due to a dependency from another DLL, then try looking at all of your DLLs in Dependency Walker. It finds all of the dependecies that a dll has. This is usually only when they are actually being used/bound, but you can also use the Fusion Log Viewer to see where all DLL binds are being bound from.
You could have a a look at reflection mechanism of asp.net or if not you could run trace using firebug for cross reference on browser ,
We're in the middle of changing from VSS to Subversion and we have a website project on our Subversion Repo. We've removed the Bin folder as it causes all kinds of chaotic tree conflicts since our development solution contains some Class Library projects the Website project depends on (set up as project references in our solution). We also have a couple of 3rd party library DLLs in the Website's Bin folder too.
The next phase of our project involves a designer modifying themes to our website. I'd like for him to be able to just open the Website project in VS 2005, modify the CSS files he needs to on his working copy, and test his files on his localhost. He'll need the most up-to-date DLL files for him to be able to do this.
Is there anyway to add the Bin folder DLLs to subversion, and configure TortoiseSVN or subversion so that we can commit our newest DLLs (project dependencies in developer's solution files) but ignore them on update (per client I guess)? It would also be handy to have our 3rd party website dependencies on Subversion too.
You should not put 3rd-party assemblies into the bin folder. In fact, you should assume that the bin folder will be emptied before each build. It is a place to put the output from a build, not a place to put inputs.
Put these binaries in to some other folder, maybe "3rdPartyAssemblies". Use a file reference to these files, and they'll be copied into the bin folder, as outputs.
Would it not be possible to structure it like this:
Trunk/
WebApp/
ClassLibrary1/
ClassLibrary2/
ClassLibrary3/
3rdPartyDlls/
build.bat
The web app is what pulls all the class libraries and the 3rd party dlls in to the WebApp's Bin folder (All of these will be referenced via relative links). You can then setup TortoiseSvn to call the build.bat file on update through client side hooks. You would also setup IIS on the designer's machine to point to the WebApp directory.
As other users have pointed out, you could use svn externals to pull in those enterprise wide class libraries.
What most everybody else has said regarding '3rdParty' is correct.
You may also consider svn:externals to pull in related directories including a '3rdParty' assemblies directory, or even output directories from builds that can be triggered by a check in to assure currency.
The approach we've taken is, rather than having the Libraries in the same solution, they have separate solutions and we (well, our Build server) compiles them and checks the compiled DLLs into sourcecontrol under "Dependencies" which is always mapped to C:\Dependencies on all developers machines. We then use file references to this folder from the website project.
Thi way you can give your designer the Website project along with a copy of C:\Dependencies and they'll be none-the-wiser =)
We don't sourcecontrol the bin-folder since it would be updated everytime you run a compile. Instead, we keep references to 3rd part libs in a separete folder that is under version control, that we have references to in our project.
With this setup and using "copy local = true", they are automatically added into bin upon compilation.
Secondly, we will only commit new binary files when we update the 3rd-part binaries.
This approach is also possible to do for your internal dlls, so that your designer can just compile his visual-studio-solution so taht any relevant dlls would be put into his bin-folder and hence, create a functional site locally on his machine.