I have 3 C# projects, A (WPF application), B (class library), and C (class library), such that A references B, and B reference C. Project C needs to call some native methods from a C++ DLL via P/Invoke. I added the native DLLs to the C# project and marked them a "Copy to Output Directory". When I build my solution, the native DLLs show up in the output directory for Projects B and C (correctly), but not for Project A. Is there a project setting that allows these to be copied by any project that ultimately references Project C (even if not directly)? Or do I just need to post-build event on Project A to copy this files to my application output folder?
I've looked at Dependencies of references not copied to output directory, but this was referring to project references, so I'm wondering if there is a solution in my case.
I also considered embedding the native DLLs as resources and modifying my DLLImport as in this MSDN article: http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.dllimportattribute.dllimportattribute.aspx. But I get an E_ACCESSDENIED error (I've seen others with this same issue as well, as well as some concerns about triggering antivirus behavior when extracting the DLL to disk). I also noticed the article mentions linking the resource, rather than embedding it. Is this something I need to do as an MSBuild task, rather than through some project properties?
Worst case, I could just add a post-build event to my WPF application that copies the native files, but it would be nice if Visual Studio would recognize that these files should be copied.
I solved this by customizing the output for debug/release mode compiles (on the project properties window) so that all of my projects outputted to the same folder... Much like how an ASP.NET application is published where all DLLs end up in a single /bin folder. That fixed my issue.
Related
I've got ProjectA. It has a WinForm and some .resx files in it. I created a Shared Project (ProjectA-shared) and moved everything to it. ProjectA references ProjectA-shared.
When I compile the Solution with VS2013 and the Shared Project plug-in, I get the following exception when running the app:
Could not find any resources appropriate for the specified culture or
the neutral culture. Make sure "Foo.Controls.MyForm.resources" was
correctly embedded or linked into assembly "Foo" at compile time, or
that all the satellite assemblies required are loadable and fully
signed.
When I compile the Solution with VS2015, everything is OK.
I am now left wondering:
Why would there be a difference between the VS2013 and VS2015 outputs?
It looks like .resx and WinForms aren't a natural fit for 'Shared Projects': what is the best way to share this kind of thing between two projects (primarily, projects using Shared Project just so that they can target .NET 4 and 4.5)
I have created a Setup Project in VS2010 for my VC++ project and I have it generating a setup file and it includes Primary Output, Content Files, Documentation files and Resource Sattelite DLLs from my VC++ project. My VC++ project is multilanguage and hence includes language DLL files in subdirectories. My issue is that the Setup Project does not include these language DLLs (nor their directories into which they must be placed).
I would have thought that these DLLs were included in the Project Output but they are not. :-/
I know I could add them manually by referencing the files directly, but that means including a absolute reference which I would rather not do. Also, a fixed reference means Release/Debug versions of the file are not handled (only one of them is use regardless of project setting).
Suggestions?
Edit: I have now tried Setup Project, InstallShield LE and WiX. None of them include the localization dll's into the setup project (only managed a working setup with Setup Project, but could see that the other installers did not include the required dll). I can't even fint any reference to this being a know bug and I have really tried hard to find a solution to this.
Found it over there:
C# Creating a setup for multi-language
It worked. I hope it is what you were searching for.
I have 2 copies of a solution, each of which is compiled against a different version of the same 3rd party API and a different .NET framework version.
Solution A - compiled against v2012 of a 3rd party API and .NET 4.0
Solution B - compiled against v2011 of a 3rd party API and .NET 3.5
Solution A contains all the source files and Solution B links to these files (using "Add as Link" in Visual Studio).
Conditional compilation is used to include code that is specific to one solution or the other.
My solution contains some XAML (WPF Windows, User Controls & Resource Dictionaries). Solution B links to these XAML files and compiles ok, but when I run it I get a Set property 'System.Windows.ResourceDictionary.Source' threw an exception exception.
I've Reflectored over both versions of the assembly and there are differences in the resource names.
For example, one project contains a Windows/MyWindow.xaml file and the compiled assembly from Solution A contains a windows/mywindow.baml resource, while in the assembly from Solution B the name of the resource is just mywindow.baml.
Is there a way to compile the same XAML file into multiple projects?
if you are on Windows7/Vista/2008 (not XP), maybe try using Windows link not a Visual Studio Link.
http://technet.microsoft.com/en-us/library/cc753194(v=ws.10).aspx
So with a Windows link, it is the same file on disk, but appear as separate files in each project directory. (Yes, changing the file in either location changes it in both locations because the file is really in one location with a pointer in two locations)
I need some help regarding Visual Studio solution and project organization.
I have a solution with several projects. All of them are written in C# and are compiled as libraries to be used by the GUI. Some of these libraries have also dependencies with others. For example, TestExecutive needs LoggingFramework, Communications needs LoggingFramework too.
Which is the best way of organizing? I'm thinking on a folder assemblies to hold libraries' binaries in one place. Something like:
Solution
|
|-- TestExecutive
|-- LoggingFramework
|-- assemblies
There is also another problem. One of the projects uses a native C dll. Where do I have to place this library? With the librarie's assembly or with the final executable?
EDIT:
Ok, now suppose I have the WinForms program running. I have source code and binaries mixed. Which features do I need to generate something I can distribute? I mean, with all the libraries and configuration files, but without source code. I have done this before with Nullsoft installer, but I don't know if visual studio can help you doing that.
A few things here:
When one project depends on another, you can set up that dependency in Visual Studio. Right click on a project and select Project Dependencies...
For other .NET assemblies that are NOT part of your solution (3rd party tools, etc.) I do exactly what you showed here -- I have a separate folder parallel to the projects. Then I set up the assembly reference in each of the projects with "Copy Local" set to true and it works fine.
For native C dlls, it's a little different. There is no direct reference to them in the references section of the solution explorer. The compiler isn't going to look at the dll to check your p/invoke references or anything like that. You just need to make sure the dll is part of the deployment on your top level web or winforms project. It's a content file just like a css file or image or something. Just add it as a file in the project and make sure the "Build Action" is set to Content so Visual studio knows to just copy the file as part of the deployment
I set my solution folders up a bit differently than you. At the top level I have the following folders:
\build
\lib
\src
The build folder has build scripts (NAnt, MSBuild, etc). Any 3rd party assemblies (or anything I'm not building in the solution) get put into the lib folder, in an appropriate sub-folder. For example, I'll have log4net, NUnit, RhinoMocks folders in the lib folder, each containing the files needed for that dependency. The src folder has the solution and all project files.
I like this structure because it clearly delineates between the project code and the other stuff that is required by the project. Also, I usually set up some custom build tasks to copy the resulting assemblies for my project into either a \deploy or \lib\ folder. This way you don't have to hunt in the \src\\bin\\ folder to get a built assembly or the whole project; however this seems a bit beyond the scope of your question.
Btw... I didn't come up with this structure on my own, I think I started off using Tree Surgeon and evolved my process from there.
I just upgraded a solution from .NET 2/Visual Studio 2005 to .NET 3.5/Visual Studio 2008.
I have a Web Application Project "W" that has a project reference to a class library project "C".
When I build "W", "C" is compiled and copied local, and all is good.
However, if I make a change to C, or build C with a different configuration, and compile ONLY C, the output is automatically copied to W's \bin directory! And in my case, this breaks W.
This behaviour seems to be specific to VS2K8 and web application projects. I'm sure someone thought it would be nice to have studio push updates forward to referencing projects, but it's a very bad idea.
Is there a way I can turn this behaviour off? I can't find a related project or IDE option anywhere.
Create a file called "Libraries" or something else appropriate and put a copy of the DLL file from your class library project into there and have the web application project reference that file, as opposed to the project.
This will allow you to modify your class project at will, but will also force you to copy things over to make sure you have the latest and greatest in your web application. In your case, this sounds like the preferred method for you.