I need to config IIS-Express (or DevServer) to put all output assembly files in one place.
Now DevServer copies each dll to its own folder like:
C:\Users\UserName\AppData\Local\Temp\Temporary ASP.NET Files\root\3df2e06f\587c7c63\assembly\dl3\fea77c7a\42e614aee75dcc01"
I need this to enumerate assemblies, and load plugins.
Three month ago I managed to find special key to app.config, which helped.
Does enyone know this magic app.config key?
Finally found:
<system.web>
<hostingEnvironment shadowCopyBinAssemblies="false" />
</system.web>
Related
In my solution, there's a single appSettings.config file which is shared by a number of projects. It's referenced in the config files of those projects like this:
<appSettings file="appSettings.config" />
And that's all fine.
The individual config files also have Debug and Release configurations that I can use to control things like connection strings when I publish from local to live and that's also fine.
However, most of the key settings I want to change aren't in the project config files: they're in that appSettings file.
I could have two appSettings files in my solution and have the Debug > Release configuration change which one is referenced when the solution is published, but that seems a little clumsy - most of the settings are the same.
Right-clicking on the appSettings.config file doesn't give me an "add config transforms" option, so I'm guessing I can't have a Debug/Release transformation of that file itself.
Is there any other way to go about this other than replacing the whole file on publish?
I created a simple standalone SQL-table-to-class generator as a WPF application.
When I save files (e.g. a .cs class file) from that application into the directory structure of a separate web application I'm working on, it is of course not added to the solution. I have to manually add it in.
Is there a way I can automatically tag it/flag it or whatever, to be included in the web application solution?
The only solution I know of is to manually modify the .proj file and add a content include directive for the directories you want with a wildcard.
<Content Include="SomeDirectory\*" />
You will need to do this for each directory and it isn't recursive. The major down-side though, is that you must reload the project for it to pick up new files.
Personally, I consider this to be a bit of hack and would never use it in a serious project.
I'm trying to split out my web resources, images/JS/CSS into another project within my Visual Studio solution so that I can share this across all projects.
I've tried setting this up as per link below
How do you share scripts among multiple projects in one solution?
However I keep on getting
Web resource '/Scripts/myscript.js' was not found.
I'm using "add as link" to link to resources from different project but they don't see to get copied over on build.
Thanks
This is a better way of doing it.
Using information from
Copy file(s) from one project to another using post build event...VS2010
and
http://greenicicleblog.com/2010/12/01/link-whole-directories-into-visual-studio-projects/#comments
I created a folder called WebAssets along side my project. I copied all my scripts, css and images to this folder.
I then added
<Content Include="..\WebAssets\**\*.*">
<Link>%(RecursiveDir)%(FileName)%(Extension)</Link>
</Content>
to my csproj file
This worked when I published the site, but not after a build. The local webserver kept on complain about missing files.
So I added a post build event to project, like so.
<PropertyGroup>
<PostBuildEvent>xcopy /S /Y "$(SolutionDir)WebAssets" "$(ProjectDir)" </PostBuildEvent>
</PropertyGroup>
This copied all the files from the WebAssets folder to the correct location.
This example shoes the best way I have come up with so far
http://www.codeproject.com/Articles/12997/WebResource-ASP-NET-2-0-explained
However I'm not that keen on it because it means that I have to create many manual entries in the AssemblyInfo.cs file and then modify css and js to point images. Like so
<img src='<%=WebResource("MyWebResourceProj.MyResources.Test.gif")%>'>
I have some content files that I would like to share between a number of projects in Visual Studio.
I have put these files in their own project, set the build action to "Content", and the copy to output directory to "Copy if newer". I would like all these files to be copied to the bin/debug directory of the projects that reference them.
I can get it to work by including a reference to the "contents" project in each of the projects that need the files, but that requires that a minimal assembly be generated (3K). I assume there is a way, using MSBuild, to make this all work without creating the empty assembly?
Thanks to everone who took the time to make a suggestion about how to solve this problem.
It turns out that if I want my compiled content files to be treated like content files (in that they get copied to the output directory of any other project that references my project), I need to create a target which runs before GetCopyToOutputDirectoryItems, and add the full path of the compiled content files to the AllItemsFullPathWithTargetPath ItemGroup. MSBuild calls GetCopyToOutputDirectoryItems for projects on which the current project depends, and uses the resulting file list to determine the files that are copied along with the assembly.dll. Here is the XML from my .csproj, just in case someone else has a similar problem.
I have a custom task called "ZipDictionary", and I accumulate all the files that I am going to compile in an ItemGroup called DictionaryCompile. My target, "FixGetCopyToOutputDirectoryItems" is executed before "GetCopyToOutputDirectoryItems". I don't do the actual compilation there, since this target can be called multiple times by referencing projects, and it would hurt performance. The target does some transforms to get the post-compilation file names, and then returns the full paths to all the files, since relative paths will not work when copy is called from the referencing project.
<ItemGroup>
<DictionaryCompile Include="Dictionaries\it-IT.dic">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</DictionaryCompile>
</ItemGroup>
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<UsingTask TaskName="ZipDictionary" AssemblyFile="..\LogicTree.DictionaryCompiler\bin\Debug\LogicTree.DictionaryCompiler.dll"/>
<Target Name="BeforeCompile">
<Message Text="Files #(DictionaryCompile)" Importance="high" />
<ZipDictionary DictionaryFiles="#(DictionaryCompile)" OutputDirectory="$(OutputPath)">
<Output TaskParameter="OutputFiles" ItemName="DictionaryOutputFiles" />
</ZipDictionary>
</Target>
<Target Name="FixGetCopyToOutputDirectoryItems" BeforeTargets="GetCopyToOutputDirectoryItems">
<ItemGroup>
<_DictionaryCompile Include="#(DictionaryCompile->'$(OutputPath)Dictionaries\%(FileName).ltdic')" />
</ItemGroup>
<AssignTargetPath Files="#(_DictionaryCompile)" RootFolder="$(MSBuildProjectDirectory)\$(OutputPath)">
<Output TaskParameter="AssignedFiles" ItemName="_DictionaryCompileWithTargetPath" />
</AssignTargetPath>
<ItemGroup>
<AllItemsFullPathWithTargetPath Include="#(_DictionaryCompileWithTargetPath->'%(FullPath)')" Condition="'%(_DictionaryCompileWithTargetPath.CopyToOutputDirectory)'=='Always' or '%(_DictionaryCompileWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'" />
<_SourceItemsToCopyToOutputDirectoryAlways Include="#(_DictionaryCompileWithTargetPath->'%(FullPath)')" Condition="'%(_DictionaryCompileWithTargetPath.CopyToOutputDirectory)'=='Always'" />
<_SourceItemsToCopyToOutputDirectory Include="#(_DictionaryCompileWithTargetPath->'%(FullPath)')" Condition="'%(_DictionaryCompileWithTargetPath.CopyToOutputDirectory)'=='PreserveNewest'" />
</ItemGroup>
</Target>
A better possible solution would be to
place a common directory in the solution dir and place your common content files there.
in VS, in each project that should share this content, right-click add existing item, browse to the desired item(s), select, click the down-arrow on the add button and select add as link. In the project, you will notice the files are added with a 'shortcut' overlay.
In the project, select the newly added links and right-click->properties and select Build Action: content, Copy To Output Directory: Copy Always.
This is a simple solution to the problem given.
I use this technique for things like SQL scripts and partial config files (using configSource) with great success. This allows me to make changes to these files in a single location with the assurance that they will be propigated throughout the solution.
A more robust solution would be to create a project with embedded resources. This requires a bit more work to manage the content on the receiving end but may be worth it in the long run as having a bunch of loose artifacts flying about can become problematic.
Hope that helps.
A similar solution like the one Sky suggested can be found in my answer to "Is there a way to automatically include content files into asp.net project file?".
It allows to share your content but you must not touch the folder or its content inside VS because this breaks the recursive path.
This approach works best for auto-generated content - you don't have to bother about including new content files to your solution.
And of course you can reuse this in multiple solutions/projects.
We do something similar where we have "...ReleaseBuilds" that reference dlls and content we require for specific projects. Compiling copies everything to the bin debug folder and indeed creates the empty assembly.
Within Visual Studio we have a post-build event in the "...RealeaseBuild" (in project properties) that copies/deletes or run batch files to make sure we have all the files (configs, services etc etc) required and to delete the empty assembly.
HTH
In my project file, I have the following entry:
<Reference Include="Microsoft.Practices.Unity, Version=1.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<HintPath>..\..\..\..\Libraries\Microsoft.Practices.Unity.dll</HintPath>
</Reference>
which in absolute terms translates to:
C:\dev\LUT600 2.1.1\OCC600\Libraries
Somehow, when I try to compile the project, Visual Studio loads a reference from a totally different path:
/reference:"C:\Program Files\Microsoft Enterprise Library 4.1 - October 2008\Bin\Microsoft.Practices.Unity.dll.
How it resolves to this location is a complete mystery as this DLL is not referenced anywhere in this project.
I have set Specific Verion to true but it still resolves the reference from this location.
Any ideas?
TIA.
Klaus
It may be that the reference does not have the same version number as the assembly in that particular location, so it starts searching elsewhere to find a "better" match.
Rather than just taking the file you specified, VS always uses a probe path to try to find referenced assemblies. This often provides a random "pick anything with the same name" effect. On our build server I once found 996 copies of an assembly. 995 were the same, correct version, and one was the wrong version. And one day our build stopped working when for no apparent reason it suddenly decided to use the single wrong copy!
Try deleting and recreating the reference. That often helps.
In the worst case scenario, delete all copies of that assembly from your PC, except the version you wish to link to. (if possible without destorying anything you hold dear)
You most likely added the reference from the GAC(Global Assembly Cache). The long list of references that take a while to load are references from the GAC. Try removing your reference, and re-adding it by browsing to that assembly in the Add References dialog.
It could be finding the dll in the Search Path before it evaluates the HintPath. As mentioned in this post, there are two places that are searched before HintPath.
Files from the current project – indicated by {CandidateAssemblyFiles}.
$(ReferencePath) property that comes from .user/targets file.