In Visual Studio website projects (in Visual Studio 2005 or later, not web application projects where there is still a .csproj file) how is the reference information stored, and is it possible to source control it without storing compiled binaries in source control?
If you right-click on a website project and select Property Pages, the first screen (References) lists all the project references.
System.* references are listed as type GAC, and other DLL files can be listed as BIN or Project.
The problem occurs when you include something as a project reference, and then commit it to source control (for us, Subversion, ignoring .dll and .pdb files.)
Another developer gets updated code from the repository and has to manually set up all of these project references, but I can't even determine where this information is stored, unless it's in that .suo, which is NOT source-control friendly.
If you reference a .dll by file name through the browse tab, there should be a .refresh file created (nested under the dll in BIN). We put those in SVN and it works great (you may have to hand edit them to use relative paths).
References added from the .NET tab are added to web.config
Project references are stored in the solution (.sln) file. Open the .sln file and you'll see them listed:
Project("{xxxxxxx-7377-xxxx-xxxx-BC803B73C61A}") = "XXXXXXX.Web", "XXXXXXX.Web", "{xxxxxxxx-BB14-xxxx-B3B6-8BF6D8BC5AFF}"
ProjectSection(WebsiteProperties) = preProject
TargetFramework = "3.5"
ProjectReferences = "{xxxxxxxx-C3AB-xxxx-BBED-2055287036E5}|XXXXXX.Data.dll;
...
“Web Site” projects in Visual Studio are a strange thing. They seem to be an attempt to cater to traditional web developers, where a “site” is just a set of files in a directory. In much the same way, when you make a “Web Site” project in Visual Studio, there is no real “project” file, like C# projects have a .csproj file. However, there is still a solution file (.sln). Normally, assembly .dll references are saved in the project file. Since a Web Site doesn’t have one, where do they go?
References to other projects
If you add a reference to another project, then an entry is made in the solution .sln file. It ends up looking like this:
Project("{E24C65DC-7377-472B-9ABA-BC803B73C61A}") = "WebSite1", "..\..\WebSites\WebSite1\", "{F25DB9D6-810D-4C18-ACBB-BFC420D33B20}"
ProjectSection(WebsiteProperties) = preProject
TargetFramework = "3.5"
ProjectReferences = "{11666201-E9E8-4F5A-A7AB-93D90F3AD9DC}|ClassLibrary1.dll;"
File System References
If you browse the file system and add a .dll file, then Visual Studio will create a “.refresh” file with the same name in the \Bin folder. This file is just a 1-line text file that indicates the path that the file was loaded from. So for example if I added “MyAssem.dll” from ....\libs, then in the Web Site \Bin folder, I would end up with 2 files copied there: MyAssem.dll and MyAssem.dll.refresh. The .refresh file would contain the text: “....\libs”. At each build, Visual Studio will check the path in the .refresh file, and if a newer .dll exists there, it will overwrite the one in the Bin directory.
Warning: Visual Studio will NOT throw an error if the file does not exist where the .refresh file tells it to look. It will just continue to use the .dll already in the \Bin folder. It will however output a Warning.
GAC References
If you add an assembly from the Global Assembly Cache, Visual Studio will enter it in the Web.config file, like this:
<compilation debug="false">
<assemblies>
<add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
Again the thing you have to watch for here is that Visual Studio assumes that if the assembly was in the GAC on your development computer, then it will be in the same place at runtime! That can get you into trouble if you maybe have Oracle.DataAccess installed on your dev machine, which would put it in the GAC, but when you deploy, you just copy the .dll into place on the production machine. It will still try to find it int he GAC and may fail at runtime.
I hope this helps clear up the oddities areund Web Sites and how references work!
I use copyprojectDll.ps1 powershell.
My folder structure is below
ClassLibraries
ThirdParty
Website/Bin
CopyprojectDll.ps1
Website.sln
ClassLibraries are code classes for my project, DAL ..
Website project includes only web files, aspx, aspx.cs ..
ThirdParty are required libraries, AjaxToolkit etc.
I compile ClassLibraries.sln
I run CopyprojectDll.ps1
I use Website.sln after this.
Sample powershell file is below.
$folders = #();
$folders +="IB.Security"
$folders +="ClassLibraries/Core.Classes"
function CopyDllsToWebBin($dll_files)
{
if ($dll_files -eq $null)
{
return;
}
$targetfolder = "./Kod/bin/"
foreach($dll in $dll_files)
{
copy-item $dll.FullName -destination "$targetfolder" -force #-Verbose
}
}
function CopyDllsToThirdParty($dll_files)
{
$targetfolder = "./ThirdParty/"
foreach($dll in $dll_files)
{
copy-item $dll.FullName -destination "$targetfolder" -force #-Verbose
}
}
$dll_output_folder = "/bin/debug";
foreach($folder in $folders)
{
$dll_files = Get-ChildItem -Path $folder$dll_output_folder -include *.dll -Recurse | sort-object Name
CopyDllsToWebBin($dll_files)
$dll_files = Get-ChildItem -Path $folder$dll_output_folder -include *.pdb -Recurse | sort-object Name
CopyDllsToWebBin($dll_files)
$dll_files = Get-ChildItem -Path $folder$dll_output_folder -include *.xml -Recurse | sort-object Name
CopyDllsToWebBin($dll_files)
"Copied $folder$dll_output_folder"
}
$dll_files = Get-ChildItem -Path "ThirdParty" -include *.dll -Recurse | sort-object Name
CopyDllsToWebBin($dll_files)
$dll_files = Get-ChildItem -Path "ThirdParty" -include *.pdb -Recurse | sort-object Name
CopyDllsToWebBin($dll_files)
$dll_files = Get-ChildItem -Path $folder$dll_output_folder -include *.xml -Recurse | sort-object Name
CopyDllsToWebBin($dll_files)
"Copied ThirdParty"
date
Related
I have an incredibly simple .NET core console application that I'd like to publish into a self contained executable. My application uses an the Microsoft.Extensions.Configuration.Json package so I can use an appsettings.json file.
From the command line, in the .csproj folder, I run
dotnet publish --self-contained true -r win-x64
. Inside my Debug folder, I see a netcoreapp2.1 folder and then the win-x64 folder. Inside that folder, I see the following:
publish -> folder
myapp.deps.json
myapp.dll
myapp.exe
myapp.pdb
myapp.runtimeconfig.dev.json
myapp.runtimeconfig.json
appsettings.json
hostfxr.dll
hostpolicy.dll
Am I supposed to copy just the files from this directory or do i have to copy the entire publish folder along with the files to my destination on a Windows Server? Or did I miss a switch to condense these items down further so movement from server to server is even simpler?
Copying just the files from the win-x64 directory was not enough. I needed to copy up the entire publish folder and run the application from that directory, otherwise error messages such as not being able to find a dependency would occur.
I am getting an error of "Could not load file or assembly 'Microsoft.AI.Web' or one of its dependencies" in the browser of my asp.net app. Microsoft.AI.Web is from Microsoft.ApplicationInsights.Web NuGet package.
I noticed this:
LOG: Appbase = file:///D:/Source/Workspaces/AppName/Branches/Main/Application/WT/
LOG: Initial PrivatePath = D:\Source\Workspaces\AppName\Branches\Main\Application\WT\bin
the dll in question is located at D:\Source\Workspaces\AppName\Branches\Main\Application\packages\Microsoft.ApplicationInsights.Web.2.4.1\lib\net45\Microsoft.AI.Web.dll
As for personal dll's -- In the project-->properties-->build-->output path--> I have it set as "..\Any\Debug\". When I build the project the DLL's populate there.
I checked References and code in .csproj file and all the dll are located where I specified to.
I am not sure why it's trying to look at the bin file of the project when I told the output is somewhere else AND to look for the dlls in that same folder(through references and .csproj file). How do I make it so that VS will look for the dlls in the folder path I want instead of "WT\bin"?
When I change my project output path to "bin", it can detect the dll's there EVEN though the path of the dll remains the same( D:\Source\Workspaces\AppName\Branches\Main\Application\packages\Microsoft.ApplicationInsights.Web.2.4.1\lib\net45\Microsoft.AI.Web.dll).
Since it's a Microsoft strong signed DLL, add it to the server's GAC.
If you place it in the GAC, it'll find the file automatically. Another plus there is that if you need it for another project deployed on the same server, you don't need to deploy it again.
Here's some information on how to install a DLL into the GAC on the server machine, assuming gacutil is not installed there. Look at the accepted answer, not the question.
Drag and drop a DLL to the GAC ("assembly") in windows server 2008 .net 4.0
Copy gacutil.exe and gacutil.exe config from your machine to the server's C:\Windows\Microsoft.NET\Framework\v4.0.30319
Then run on the server:
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\gacutil.exe" /i "PATH TO YOUR DLL"
I'm using an msbuild command line script to publish a c# web project from team city out to a live server.
After wrestling with IIS perimisions etc it all works well...
....apart from the fact that the font files end up not being copied to the right directory (they end up on the bin directory)
/t:rebuild
/p:Configuration=Deploy
/p:OutputPath=bin
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MsDeployServiceUrl=https://<server>/MsDeploy.axd
/p:username=<username>
/p:password=<password>
/p:AllowUntrustedCertificate=True
/p:DeployIisAppPath=<sitename>
/p:MSDeployPublishMethod=WMSVC
Any suggestions as wo what I can do to force the files to go to the right directory?
Make sure the fonts are included as "Content" by right clicking on them in Visual Studio and selecting properties and changing the "Build Action" to "Content". Also ensure "Copy to output directory" is set to "Do not copy"
When we run ASP.NET through the debugger it runs in a special directory like:
C:\Program Files\Common
Files\Microsoft Shared\DevServer\10.0
I dont know if this directory is configureable. The problem is that if you have a file such as Transfer.xsl then you set its property "Copy to Output Directory" to "Copy if newer". This copies the file out to the bin.
But, we are not running inside the bin. So if I use a relative path
StorageFolder\Transfer.xsl
It becomes...
C:\Program Files\Common
Files\Microsoft Shared\DevServer\10.0\StorageFolder\Transfer.xsl
But, Visual Studio does not copy files here even when you set the property described above.
In the past I got around this problem by writing a pre-build routine to xcopy the dependencies to this "temp folder". It works, but flippen sucks caseadillas.
Is there a better way?
In ASP.NET application you could use the App_Data special folder to store files. And when you want to get the full path to this file you use the MapPath method:
string fullPath = Server.MapPath("~/App_Data/Transfer.xsl");
Which folders may I not commit to subversion server?
I'm talking about an standard asp.net web application in Visual Studio 2.008. I think the bin folder because it's files are regenerated, is there any other?
We put this string as the svn:ignore property on all our projects:
*.pdb
*.exe
*.dll
debug/*
release/*
*.user
*.suo
obj/*
bin/*
obj
bin
VSMacros80
For any C# project I would recommend to ignore the following files/directories:
Visual Studio files to ignore
*.pdb — Files that hold states information when debugging.
*.exe — Executable binaries.
*.dll — Library binaries.
debug/* — Folder used by Visual Studio to store a lot of debugging information
release/* — Folder used by Visual Studio to store binary releases.
*.user — Configuration per user.
*.suo — Options settings per user stored in binary format.
obj — Folder used by Visual Studio to store binary objects used while debugging.
bin — Folder used by Visual Studio to store compiled objects.
VSMacros80 — Folder used by Visual Studio to store macros.
Other files to ignore
packages — Folder used for NuGet references.
*.log — In case of having logs written in the source folder (this should not happen).
Note: Remember to add these pattern to be ignored recursively.
Extra (copy-n-paste)
*.pdb
*.exe
*.dll
debug/*
release/*
*.user
*.suo
obj
bin
VSMacros80
packages
*.log
obj is another one, as they're debug symbols built during compilation.