I made a library which uses .xml files for configuration. But in the core project, which use this library, ressources are not copied. I added a reference to my library.dll but of course there is nothing that says i need to include /configuration folder of the lib project.
How can i achieve that ? (manual copy is excluded)
ps: im working in c# with visual studio 2012 ultimate. both project are c#. One generate a library (dll etc..), other is executable project.
Thanks in advance :)
Right click and select Add > Existing item to include the resources into your project.
After including them, select them under the Solution Explorer, right click and select properties. Look for Copy to Output Directory, and set it to Always. That should copy the files along with your project.
Another option if needed, may be to set Build Action to Embedded Resource, but that might make it a little more complicated (but not impossible) to access the files from your application.
Update: Accessing a file that is embedded is a little more messy, but this other SO question might help you out.
Related
I have a WPF app that works with local SQLite and Entity Framework Core. I want to distribute my app using ClickOnce.
Everything works fine when I run it using Visual Studio 2017. But app had a crash on a start when I used ClickOnce. The crash was so early so I couldn't even log the exception. After some time I found that in publish folder some dlls were missed. For example System.Runtime. All references are NuGet packages. Then I found that despite of I have a reference to the dlls in my project ClickOnce application files list doesn't contains it.
The only solution I have found for now is to add missed dlls as files in root of my project and set build action to Content. In ClickOnce application file dialog I set publish status to Include.
It works now but it looks like not the best way to do it. The question is why they are missed in the first place. More likely I missed something or I am not understand the root of the problem.
UPD:
You can find an example code here.
It works from Visual Studio but crashes on a start when you try to install it as ClickOnce application.
UPD: The problem was fixed in Visual Studio Professional version 15.6.1
There are two ways solving solve this.
At first, you have to go Properties → Publish → Application Files, and at this place, make your DLL files include in your project
But if it does not work, go to References and make the DLL file CopyLocal = False. You add a DLL file like Existing Item in your project and make them Copy Always.
It will work correctly.
But for your sample I watch this and I solved it. Look at this image:
You have four DLL files. You need do this for them:
System.Diagnostics.Tracing.dll
System.Reflection.dll
System.Runtime.dll
System.Runtime.Extensions.dll
At first go to your reference and make them Copy Local False:
Then go to the path of each DLL file and add them like Existing Item, and then make all of them Copy To Output Directory CopyAlways
Then Publish it and run it like in this picture. I run it from publish file and it works.
Even if you set the dll to copy local, the dll will not get copied over unless you actually use the dll in your code. You might try adding System.Runtime in your code somewhere like this maybe?
var dummytest = System.Runtime.GCSettings.IsServerGC;
Based on Issue 9 on https://blogs.msdn.microsoft.com/bclteam/p/asynctargetingpackkb/ I was able to do the following:
Symptom
ClickOnce applications targeting .NET Framework 4.0 that reference the Microsoft.Bcl or Microsoft.Bcl.Async packages may experience a TypeLoadException or other errors after being installed.
Resolution
This occurs because ClickOnce fails to deploy certain required assemblies. As a workaround, do the following:
Right-click on the project and choose Add Existing Item
Browse to the folder where the System.Runtime.dll lives
In the File name text box paste in the path of the file
Click the down-arrow next to the Add button and choose Add as Link
In Solution Explorer, holding CTRL select System.Runtime.dll
Right-click the selection, choose Properties and change Copy to Output Directory to Copy always
Republish
Having a bit of an issue here. I'm creating an application in Visual Studio 2010 in C# (Windows Forms).
The UI is going to be done in a WebBrowser (so I can use jQuery goodness and for ease of development).
For this I want to create a folder called HTML which will store all my HTML files and my javascript files.
My colleague tells me to create the folder separately and copy and paste into the compiled application directory referencing the files using: System.AppDomain.CurrentDomain.BaseDirectory.ToString() + "HTML\\FirstPage.htm" etc...
This seems strange to me. His argument is sound - if you need to edit/change anything then you don't need to open your VM (we're on Macs) open Visual Studio, edit, recompile, redistribute etc you just open the HTML files in the application directory. (my argument to this was that its just not that much extra work!)
I can see problems coming when different versions of the HTML files start getting mixed up and such, and to me it feels more "right" to compile the files directly as resources - OR... at least have them as files within the project explorer in Visual Studio.
So my question is: What would be the best way to do this? Would it be best to compile the HTML files as resources (and how would I do that? I'm very new to all this)? Or would it be better to do it the way my colleague said? If so is there a way to get Visual Studio to automatically copy the latest version of the files into the application directory at build time?
Thanks a lot.
No need for resources, they are far less manageable.
Easiest solution will be to add the folder with all the files to the project, and then, in their properties set:
Build Action = Content
Copy to Output Directory = Copy if newer
That's it!
Now whenever you compile your project, all these files would be updated with the latest version.
I finished a project.I am trying create a setup .
My Problem is that :after I create setup project dll files that I used in project added to same folder with my .exe file like
ApplicationFolder(Folder)
Devexpress.Data.dll
Devexpress.Util..dll
.
.
project.exe
but I want to get it different folder.
like
ApplicationFolder(Folder)
MYDLLFILES(Folder)
project.exe(exe file)
how can I make this? Thanks a lot
This is not only a problem of setup. unless you are already handling this in the app.config and/or with appdomain.assemblyresolve event your application will not work at all on the user's machines once those required references will not be available in the same folder if the .exe file.
Surely you could isolate every single file and tell the setup project where to put it but your program has to be modifief to then look for those files in those other locations.
I accidentally faced this problem today, I want to add some separate dll files into the setup package (I have to do this because I can't add reference of these dll files into my C# program , these dll files are of 3rd-party software).
I did as following:
Right click on Setup Project > Add > Assembly and then browse to dll which I need, then press OK button.
These dll files will be included into Setup project, and will be packaged into setup file also.
Hth.
The problem is that Visual Studio setup projects will automatically include referenced DLLs for you so you won't be able to customize their location with these setup projects.
See also the following articles by DevExpress:
How to deploy WinForms applications on client machines
How to distribute applications which use Developer Express .NET Windows Forms controls
The second article explains how to register DLLs copied to a different location.
By the way we're also also deploying a big app using these VS setup projects and our base installation folder is full of DevExpress and other DLLs. I agree that it looks totally ugly and I'd also prefer a clean structure with a lib subfolder, but nobody cares about that. Customers don't start our application from the installation folder, they use the shortcuts.
My problem is that DLLs needed by my ClickOnce app are cluttering my project folder and I would like to move them to a bin folder but don't know a simple way to do so and still get the files to distribute.
To explain:
I'm distributing a C# app with ClickOnce. It has the following components:
One C# application
One CLR DLL
Umpteen C++ DLLs
All of these build to a tidy little bin folder.
Now the CLR DLL is referenced from the C# project, so it copies and deploys fine.
But I also want to distribute the C++ DLLs as part of the ClickOnce project, so I've done the thing that people say to do, which is add them to the C# project (drag ... drop), and in Properties, set Build Action to Content and Copy to Output Directory to Copy if Newer.
ClickOnce seems to deploy these files quite nicely.
The problem, though, is that now I have a bunch of binaries dumped into my C# project folder (and appearing in the project root in the IDE), which mixes executable files with source files in a way that is extremely obnoxious.
Can anyone clue me in to a simple way to keep all my DLLs in the output folder where they belong, and also have them distributed by ClickOnce?
Move you C++ DLLs somewhere sensible then when you add them to the project choose to add them as a Link instead of the standard Add which copies the files to the project folder.
To do this follow these steps:
Right click the project file and choose add existing file.
Navigate to the location of the file(s).
Click the down arrow next to the Add button and select Add as Link
I have a C# project in MS Visual Studio 2008 that I would like to share on Google Code...I am not sure exactly which files I should be sharing on Google Code if I want to involve other contributors? What I am exactly unsure about is whether to share the entire solution folder or just the .cs files? And if it's the latter how does a contributor go about building the solution and the directory structure?
Thanks
Generally I would include the project file(s) and solution file(s) as part of the source code in a team environment (such as at work), especially if they contain anything that's needed for the proper building of the code (build events, DLL references, etc.). The user file(s) and suo file(s) and stuff like that aren't needed, those are user-specific. But this is in an environment where it can be safely assumed that everybody is using Visual Studio, even the same version.
The code itself doesn't need the project/solution files to be built, and the less you can depend on them the more open-source-friendly the project really is. If the code can be properly built from the command line, or with a tool such as NAnt, then an open source project may be better off with that. So, just from a separation of concerns perspective, try to keep the dependency on the project file(s) as light or non-existent as possible.
Overall, including the project file(s) and solution file(s) is fine if your intended audience is expected to be using Visual Studio.