In Visual Studio when I linked a file from one project to the next, I get the following error when an attempt is made to load the linked resource. This only happens when the linked file is within a folder(s).
Error:
Message="'pack://application:,,,/projectName ;component/ResourceDictionary .xaml' value cannot be assigned to property 'Source' of object 'System.Windows.SharedResourceDictionary'.
Example:
Project1.Resources
|
|--> MergedResourceDictionary.xaml
|--> ProjectResourceDictionary.xaml
|--> Folder
|
|--> SharedResourceDictionary.xaml
Project2.Resources
|
|--> MergedResourceDictionary.xaml
|--> ProjectResourceDictionary.xaml
|--> Folder
|
|--> SharedResourceDictionary.xaml **LINKED**
If in the MergedResourceDictionary.xaml we merged these dictionaries, then the "SharedResourceDictionary.xaml in Project2 will not be found. However, if the SharedResourceDictionary.xaml is linked at the root of the project then the resource is found at runtime.
**NOTE: In the "obj/debug" of project2, all linked resources are at the root directory, whereas in project1 resources remain within the folder structure assigned in the project.
Steps to recreate
This happens at runtime. Steps are as follows (using files listed in original post).
1) Create SharedResourceDictionary in Project1, within "Folder"
2) Create "Folder" in Project2, then add "as link" SharedResourceDictionary within the folder
3) Build and run app
4) App will not be able to find the SharedResourceDictionary.xaml, due to it residing within the Folder. Removing the file from the folder structure will work fine as a linked file.
I appreciate any assistance,
Chris
I spent sometime working with Microsoft support on this problem. It is a bug with MsBuild and doubtful to be something they fix in the future.
I have found a workaround for anyone that is interested:
Create a PostBuild event that runs LocBaml and creates the folder structure that you require and places the files in the correct folder.
Hope this helps.
Related
I'm trying to load a global shared library using the #Library("xxx") annotation.
The "Retrieval method" in the global settings is set to "Git".
The library is located in a subfolder within the git repository, e.g.:
my-library
+-- src
+-- com
+ ...
When starting the build, jenkins loads the complete repository and looks for the "src" folder in the root directory. I got the following error message:
ERROR: Library xxx expected to contain at least one of src or vars directories"
However, I want Jenkins to use the library from the "my-library" subfolder
I was wondering if it is possible to override/add to the template paths for Playframework? For instance, the default templates are looked under views folder and are compiled automatically. These templates are further reachable directly using a URL without any additional config.
---app
|-controllers
|-models
|-templates //How do I compile templates under this folder?
|-views
What I would like to know is if it is possible to add a custom path in addition to the views folder that is also compiled with the build process. Alternatively, is it possible to block certain templates to be not reachable by direct URL ?
Thanks in advance!
Under the app directory, Play should automatically compile anything that looks like a Twirl template - that is, has a registered extension such as *.scala.html - regardless of what directory it's in. The views directory is just a convention, and compiling templates under an app/templates directory should already happen.
If you open an SBT prompt you can verify this by running the command:
show twirlCompileTemplates::sourceDirectories
Which should give you something like:
[info] my-project/compile:twirlCompileTemplates::sourceDirectories
[info] List(/home/me/my-project/app)
For adding a templates directory outside the app folder, you should be able to add something like the following in your build.sbt (for example, the directory extra_templates):
import play.twirl.sbt.Import.TwirlKeys._
sourceDirectories in (Compile, compileTemplates) += file("extra_templates")
I have a TeamCity (9.0.2) build configuration which contains the following artefact path pattern:
App\Agent\**\bin\%env.Configuration%\** => Deployment\AgentBuildPackage.%env.ApplicationVersion.EMX%.%system.build.number%.zip
which will create a file named something like AgentBuildPackage.4.5.0.185.zip in an artefact folder named Deployment
The current structure is like this:
Deployment/
AgentBuildPackage.4.5.0.185.zip/
MyFirstServiceFolder/
bin/
Debug|Release/
All the Files
The artefact archive contains all the folders it finds under App\Agent which is great. What I can't figure out is how to flatten those individual folders so they no longer contain the /bin/Release sub-folders.
What I want is
Deployment/
AgentBuildPackage.4.5.0.185.zip/
MyFirstServiceFolder/
All the Files
Can anyone tell me how please?
You can specify target folders within your target archive by using the ! character after the name of the .zip file. Like this:
folderA\** => output.zip!/afolder/
Depending on how many service folders you have, this could be quite verbose, as you'll need to do it for each one, but it should do what you've described:
App\Agent\MyFirstServiceFolder\bin\%env.Configuration%\** => Deployment\AgentBuildPackage.%env.ApplicationVersion.EMX%.%system.build.number%.zip!/MyFirstServiceFolder/
Here's the documentation page on specifying artifact paths if you haven't seen it yet: https://confluence.jetbrains.com/display/TCD9/Configuring+General+Settings#ConfiguringGeneralSettings-PathsPatterns
I'm working on a project which uses JAAS and unfortunately for me Tomcat requires a file to be put in a META-INF folder in the root of the war
app.war
|__META-INF
| |___context.xml
...
I think that it's already weird since the default META-INF location for WAR's is in the classes folders.
app.war
|__WEB-INF
| |__classes
| |__META-INF
...
So I'm using Maven, which states that anything in src/main/resources/META-INF will be copied to the appropriate place, which it does. The weird thing is that it is also creating a META-INF folder in the root of the file structure leaving me with 2 META-INF folders.
Project Structure
app
|__src/main/java
|__src/main/resources
| |__META-INF
| |__context.xml
...
After mvn package
app
|__META-INF [1]
|__WEB-INF
| |__classes
| |__META-INF [2]
| |__context.xml
...
So, if the war standard states that META-INF should be under classes folder, as in #2, why maven war creates the #1 folder. And is there a way to make it copy files into that folder instead of #2?
Regards
So I found this:
Two Meta-Inf folders - normal structure?
which states that having 2 META-INF folders is not a problem. Digging a little I found:
JAR File Specification
which states about the META-INF folder:
A JAR file is essentially a zip file that contains an optional META-INF directory. ...The META-INF directory, if it exists, is used to store package and extension configuration data, including security, versioning, extension and services.
and this:
JSR-000315 JavaTM Servlet 3.0
which, on section 10.6, states about the WAR file structure:
When packaged into such a form, a META-INF directory will be present which
contains information useful to Java archive tools. This directory must not be directly
served as content by the container in response to a Web client’s request, though its
contents are visible to servlet code via the getResource and getResourceAsStream
calls on the ServletContext. Also, any requests to access the resources in META-INF
directory must be returned with a SC_NOT_FOUND(404) response.
So from the WAR spec the right place is WEB-INF/classes/META-INF. Yet, since war is a special jar file, it makes sense to have /META-INF as a point for extensions. One can see such different uses in JPA persistence.xml vs. Tomcat context.xml files: the former should be placed in WEB-INF/classes/META-INF while the latter in /META-INF.
I am having a hard time adding a Visual Studio Solution with multiple projects to my repo. I am using VisualSVN. Here is my directory structure
c:\-----
|
---Projects
|
--MyApp
|
---Project1 (The solution is in this project directory)
---Project2
---Project3
When I select "MyApp" as the working copy root, nothing is added. If I select one of the project folder, only 2 are added.
Here's the structure I use with success:
dev
|- Project root folder (solution file here is the key)
|- Class Project
|- Class Project
|- Web Project
|- References
|- Resources
What I'm suggesting is that you should move your .sln file to the top level then import.
Another advance approach.
Each project has it is own trunk with following structure
trunk
|- .sln
|- src
|- ClassProject
|- Web Project
Then in a separate svn directory create sub directory for every solution you need. For example you can have AllProjects, WebOnly, DALOnly.
And using svn:externals bring every project you need (ClassProject etc.) in given case.