Re-compile config file for WPF application? - wpf

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

Related

What is the difference between control and control.in files in debian packaging

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.

The component 'LiveCharts.Wpf.DefaultLegend' does not have a resource identified by the URL '/LiveCharts.Wpf;component/defaultlegend.xaml'

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.

eclipse include custom files (c)

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.

How to use JST namespace in generator-backbone?

By default (in project's grunt file) the templates.js file located in .tmp directory (generator-backbone), so am I missing something or this feature just don't work out of the box and I need to put additional paths in require.config?
Obviously if I will not add anything the JST will not be defined, right?
Note that I initiated the projects with Handlebars as the templating framework.
Ah - sorry for trashing SO. Obviously I've messed up paths in my Grunt.js.
Only .tmp/scripts directory is mounted and I've added app to the path additionally, so the files was not served at all.

Passing in a file path to FileReader

Using Netbeans, I am trying to pack some text file resources that are read by a FileReader into a JAR file, but since the text files aren't located in the resources folder, the JAR cannot find them. How can I tell the filereader where to look for the files? (Such as "/src/resources/maps/level1.txt" in my case.)
Currently, the text files are stored in the project folder and can be read from there using "filename.txt"
Hmm. this sounds like two questions. First, resources get packed into a JAR file and can't be read directly as files (yes, you can execute classes on "exploded" directory mode but your code shouldnt depend on this). Once you have generated a JAR file containing your classes and the resources, you can access the resource using an InputStreamReader, not a FileReader
new InputStreamReader(this.getClass().getResourceAsStream("/maps/level1.txt"));
The reason that getResourceAsStream() is on the Class object, is that sometimes resources are placed in same package as a class. Using..
this.getClass().getResourceAsStream("level1.txt")
without a / slash at the front of the path, this would try to locate this in the same package as "this" object.
When resources are in the root package, or have their own directory structure, /maps/ for example. You can call this.getClass() on any class (in the same classloader) to find the resource.

Resources