Why is it that when my Silverlight project is built, the output directory contains a bunch of culture specific directories:
ar\System.Windows.Controls.resources.dll
bg\System.Windows.Controls.resources.dll
ca\System.Windows.Controls.resources.dll
etc etc etc
Also the root of the build output contains:
System.Xml.Linq.dll
System.windows.Controls.dll
I have gone through the projects in my solution and made sure that "Copy Local" is set to false for all the referances of the mentioned dll files.
Those 2 files were set to true, but I did switch them to false. Despite my effort to google an answer, I remain stuck.
You have dependent libraries or DLLs or references that expect these SDK assemblies.
Those directories contain the language-specific resource files and will be there if the System.Windows.Controls assembly is included in any way in any part of your project or its dependencies.
Double check that ALL REFERENCED ASSEMBLIES are set to copy local false.
Related
I'm confused how "control" and "control.in" files works and what exactly is the difference between them.
I looked into a postgresql extension's debian folder and both files contains the same code, but the packaging build fails if I remove control.in.
I looked into the documentation of control fields but didn't get what I was looking for.
The "control" file is used by Debian package managers to specify the metadata and dependencies of a package. The "control.in" file is a template file used to generate the "control" file. It may contain variables that get replaced by values during the package build process. The package build may fail if "control.in" is removed because it is used to generate the final "control" file.
So upon further review, I found, as answered by #fahad-zaheer ,
Control.in serves as a template to build control file and after specifying the variables to make a generic control.in file which can be dynamic in nature,
We can create the control file by :
pg_buildext updatecontrol
This will look for control.in in the same directory, and will replace all the variable like postgreSQL-$Version with the value of $version by fetching from environment variable or if initialized in the control.in itself.
The main difference between the two is that "control.in" is a template file that gets processed during the packaging process to generate the final "control" file.
The reason why the build fails if you remove the "control.in" file is that it is used as a template to generate the "control" file, which is required for the package to be built and installed properly. The "control.in" file contains variables and placeholders that are replaced with actual values during the package building process, so it's essential to have it in place.
I have found numerous articles on StackOverflow and elsewhere stating that if you wanted to output your files to the bin folder using ClickOnce, you should set the
BuildAction: Content
CopyToOuputDirectory : Copy if newer
but some of my binaries are located in a Dependencies subfolder located in the root of my project and when I publish the content, they are being outputted to
<wpf app folder>\dependencies instead of being in the <wpf app folder> causing my app to not function properly.
Any suggestions on how I can change this to force ClickOnce to output specific files to <wpf app folder>\ irrespective of where the Source files are located.
I eventually found a work-around which I don't like but I need to move on. To circumvent this problem I added the required libraries to the root of my project as links and still set the BuildAction to Content and CopyToOutputDirectory to Copy if newer.
I thought I'd explain it with an example as it may make a bit more sense.
Project Path: C:\Work\MyApp and it contains the following sub-folders:
D:\Work\MyApp\MyApp.csproj
D:\Work\MyApp\MyApp.xaml
...
D:\Work\MyApp\Bin\Debug
D:\Work\MyApp\Bin\Release
D:\Work\MyApp\Bin\Release\MyApp.exe
D:\Work\MyApp\Depedencies\LibA.dll
D:\Work\MyApp\Depedencies\LibB.dll
etc...
The libraries are third-party tools and are actually contained in their own folder:
D:\Tools\MyThirdPartyLib\Distributation\LibA.dll
D:\Tools\MyThirdPartyLib\Distributation\LibB.dll
By having the libraries in D:\Work\MyApp\Dependencies did not work as ClickOnce would install the app in:
C:\Users\\AppData\Local\Apps\2.0...\MyApp.exe
and it installed the files located in the Dependencies sub-folder in:
C:\Users\\AppData\Local\Apps\2.0...\Dependencies\LibA.dll
C:\Users\\AppData\Local\Apps\2.0...\Dependencies\LibB.dll
Which caused my app not to work.
To get around it, I ended up adding LibA.dll and LibB.dll to the root of my project as "Linked files" and set their BuildAction and CopyToOutputDirectory but not by pointing the linked files to
D:\Work\MyApp\Depedencies\LibA.dll
D:\Work\MyApp\Depedencies\LibB.dll
but instead pointing them:
D:\Tools\MyThirdPartyLib\Distributation\LibA.dll
D:\Tools\MyThirdPartyLib\Distributation\LibB.dll
And this seems to have done the trick. My only beef about it is that now I've got 10 odd files listed in the root of my project in visual studio which I don't like:
MyApp Solution
- MyApp Project
- MyApp.csproj
- MyApp.xaml
- ...
- LibA.dll
- LibB.dll
- ...
But it will have to do for now.
Hope it helps others!
I have been programming on a winforms project for about a month days. Recently one of the form designers always show an error page.
When the project is just loaded on VS, there's no error. After I do some modification then rebuild it will show the error page of:
The component 'LiveCharts.Wpf.DefaultLegend' does not have a resource identified by the URL '/LiveCharts.Wpf;component/defaultlegend.xaml'.
and the call stack shows:
at System.Windows.Application.LoadComponent(Object component, Uri resourceLocator)
at LiveCharts.Wpf.DefaultLegend.InitializeComponent() in c:\Users\btord\Documents\Projects\LiveCharts\WpfView\DefaultLegend.xaml:line 1
at LiveCharts.Wpf.Charts.Base.Chart..ctor() in c:\Users\btord\Documents\Projects\LiveCharts\WpfView\Charts\Base\Chart.cs:line 82
at LiveCharts.Wpf.CartesianChart..ctor() in c:\Users\btord\Documents\Projects\LiveCharts\WpfView\CartesianChart.cs:line 40
at LiveCharts.WinForms.CartesianChart..ctor() in c:\Users\btord\Documents\Projects\LiveCharts\WinFormsView\CartesianChart.cs:line 46
at Controls.Chart.MyChart.InitializeComponent()
at Controls.Chart.MyChart..ctor()
I checked the path but found no 'c:\Users\btord' directory and a few days ago I moved my Documents directory to D driver.
Sometimes after I build on release it will show another error page of:
Could not load file or assembly 'LiveCharts.WinForms, Version=0.9.6.0, Culture=neutral, PublicKeyToken=0bc1f845d1ebb8df' or one of its dependencies.
And there's no error in source code of the designer at all, neither when building. The execute file can run healthily.
It seems to commonly happen when multiple copies of live charts dll's are present in a solution build.
For me it was used both in the main executable and a plugin class library building in a sub folder. The effect is two copies of the Live Charts dll's in different folders which it doesn't like.
Packages.config
If using a packages.config file to handle references you can set the LiveCharts references to "CopyLocal"=false for the extra projects. This stops multiple copies of the dll's being included the build. It will happily use the copy loaded in the main project.
Package References
Sadly there isn't an option to not copy the files when using the newer style package references.
Removing extra copies post build seems the easiest workaround I've found.
In Project Properties, Build events page, post build event command line box add
del $(TargetDir)LiveCharts.*
$(TargetDir) is your projects output path.
After build my solution (WPF application), the config file is created in project\bin\debug folder. Whenever a change is made to this config file, I have to re-compile/rebuild the project to pull the changes from the config file.
Is there a way to avoid re-compiling the project after making a change in config?
This somehow throws the whole purpose of config file.
If you talk about the App.config file (an XML file where you usually put appSettings, connectionStrings, etc): it is possible to modify this one without to recompile your project / solution. Just navigate to the project\bin\debug folder, there you'll find a file that is called {AssemblyName}.exe.config which you can edit (actually, this is a renamed version of the App.config file, this happens when the build process copies it to the output directory).
If you talk about XAML related files: these are by default not configurable because they get translated to BAML (Binary Application Markup Language) files that are embedded to the assembly in a default WPF project. If you change those you have to recompile.
You do not need to recompile your project. Your assumption is wrong.
if you edit OutputDir\{appname}.exe.config, then it will take effect immediatelly. However, if you rebuild your app, this config file is overwritten by app.config from your project folder
Not sure how to phrase the question.
I've created a few files for my c project that I would like to use for multiple projects.
Project root: ~/workspace/myproject
Files :
~/workspace/myproject/customlib/myfile.h
~/workspace/myproject/customlib/myfile.c
I was able to move them from my eclipse (Code Composer Studio) workspace and replace them with symlinks to their new location.
Custom lib dir: ~/myfiles/customlib
This is working fine but I'd rather not use the symlinks as it becomes necessary to add those symlinks to any project where I want my customlib files. Also when copy/pasting a project in eclipse it doesn't seem to understand the symlink and creates a copy of the file rather than the symlink.
I've set up an include path to ~/myfiles/ but when I compile I get a bunch of unresolved symbol errors.
My custom files depend on files from other include paths as well. (if that might be a hint as to why things are breaking)
Is there another way I can link in these files?
I figured out how I can do what I'm looking for but can't actually post the answer for 8 hours so I'll answer it here.
I was able to add the .c files as "Linked Resources" to my project.
So in the end I had an include path to ~/myfiles and a linked resource ~/myfiles/customlib/myfile.c.
Linked Resources can be found under Project Properties -> Resource -> Linked Resources -> Linked Resources(tab)
Unfortunately, my environment, Code Composer Studio 6 on Ubuntu would not allow me to actually add a linked resource through the IDE.
As a workaround I added the linked resource directly to the .project file.
~/workspace/myproject/.project
Under the section labeled "natures" I added
<linkedResources>
<link>
<name>myfile.c</name>
<type>1</type>
<locationURI>$%7BPARENT-2-PROJECT_LOC%7D/myfiles/customlib/myfile.c</locationURI>
</link>
</linkedResources>
The "$%7BPARENT-2-PROJECT_LOC%7D" refers to ~/workspace/myproject/../../ (a.k.a. ~/). The 2 tells it how many ../'s
In case you don't get the locationURI right the first time you should be able to edit the file path from Project Properties -> Resource -> Linked Resources -> Linked Resources(tab)
You can use any defined build variables for the locationURI. Here is another way to write the location URI. PROJECT_LOC/../../myfiles/customlib/myfile.c
Since this is an eclipse project file it will be overwritten with whatever eclipse decides is the proper format for locationURI
You can place the linked resource into a folder in your project by modifying the tag. projectsubfolder/myfile.c. This will create a folder projectsubfolder under your project directory. ~/workspace/myproject/projectsubfolder
Unfortunately this isn't an optimal solution as I will need to add linkedresource entries for every source file I create in my custom lib. CCS fumbles the linked resources when doing a project copy/paste, requiring you to add the linked resources again to your copied project.
In the end it feels like a solution but it really doesn't have much benefit over symlinked files. The only one being that when I copy/paste a project I will know the project isn't using the correct files when it doesn't compile. (symlinking will make a working project with copies of the files instead of the originals)
I imagine I will need to learn about creating .lib files to make the inclusion a little more pain free.