I'm trying to share files between multiple projects in Visual Web Developer 2010 Express, so I can reuse some functionality, and not having to manage two separate versions of code.
I tried to add a css file from my first project into the second with : Add existing - Add as link. So far so good, but when I include the css file inside my master page :
<link href="../../../Konnektor/Konnektor/WebRole1/StyleSheets/CSS_Backoffice.css" rel="stylesheet" type="text/css" />
it is not working inside the browser, because it cannot find the resource, as it is searching for
http://127.0.0.1:81/Konnektor/Konnektor/WebRole1/StyleSheets/CSS_Backoffice.css
What is the best (better) way to proceed ? Also I suppose that this technique will work when deploying on Azure, because the linked file will be a part of the package ?
Thanks guys
Related
So I have this:
/projectA/index.html
And for the sake only for testing I want to have this in index.html
<script src="../projectB/somefile.foo"></script>
Of course, when I run visual studio, my foo file cannot be found because it is above the project "root".
Is there any way to allow IIS to gain access to projectB?
I am using TypeScript with Visual Studio 2013.
Note: I did google this, but I find asp stuff. As far as I am aware, this is not relevant to me?
Thanks!
The browser is trying to access the file at ../projectB/somefile.foo relative to where the current page is. Ask yourself this question, if you were using a web browser, how would you navigate to ../projectB/somefile.foo?
I'm going to make a bit of an assumption and guess that index.html is at a url that looks something like this:
http://localhost:55685/index.html
Now, as you pointed out, it doesn't really make sense to go up a directory using ../ when you are already in the root directory.
You have two options I can think of right now. One is that in the project's properties, on the Web tab you can configure a Project Url for projectB. For example http://localhost:55685/projectB. Then in your app do this:
<script src="http://localhost:55685/projectB/somefile.foo"></script>
You'll have to do some additional configuration if you ever deploy your application, but it's a solution that works if you just need it for development.
Another option is to copy the script files from projectB into projectA. I would recommend this, especially if projectB isn't going to be deployed somewhere. If you are trying to access some TypeScript files, you can use a method similar to what is outlined in this other answer. Otherwise, just make a build event that runs a script to copy all your script files into projectA. After that, reference the script files you need at the location you copied them to in projectA.
I'm trying to split out my web resources, images/JS/CSS into another project within my Visual Studio solution so that I can share this across all projects.
I've tried setting this up as per link below
How do you share scripts among multiple projects in one solution?
However I keep on getting
Web resource '/Scripts/myscript.js' was not found.
I'm using "add as link" to link to resources from different project but they don't see to get copied over on build.
Thanks
This is a better way of doing it.
Using information from
Copy file(s) from one project to another using post build event...VS2010
and
http://greenicicleblog.com/2010/12/01/link-whole-directories-into-visual-studio-projects/#comments
I created a folder called WebAssets along side my project. I copied all my scripts, css and images to this folder.
I then added
<Content Include="..\WebAssets\**\*.*">
<Link>%(RecursiveDir)%(FileName)%(Extension)</Link>
</Content>
to my csproj file
This worked when I published the site, but not after a build. The local webserver kept on complain about missing files.
So I added a post build event to project, like so.
<PropertyGroup>
<PostBuildEvent>xcopy /S /Y "$(SolutionDir)WebAssets" "$(ProjectDir)" </PostBuildEvent>
</PropertyGroup>
This copied all the files from the WebAssets folder to the correct location.
This example shoes the best way I have come up with so far
http://www.codeproject.com/Articles/12997/WebResource-ASP-NET-2-0-explained
However I'm not that keen on it because it means that I have to create many manual entries in the AssemblyInfo.cs file and then modify css and js to point images. Like so
<img src='<%=WebResource("MyWebResourceProj.MyResources.Test.gif")%>'>
I am building a web project in Visual Studio that uses dojo, but I am unsure of how to link in the 3rd party dojo files so they get copied to the output directory.
In the past for things like jQuery, I placed the jquery.js file in a separate folder, went to "Add Existing Item," added jquery.js as a link, and set Visual Studio to copy it to the output directory (if newer). This worked great.
For dojo, there are hundreds (if not thousands) of related external files. This is not practical to add to Visual Studio (though I did find a way to do it in bulk).
This makes me think that I am approaching this incorrectly. How can or should I include something like dojo in a C# project without having to reference each file? Should I use a post-build step to robocopy the files into the output directory?
My goal is to be able to build multiple projects which all use dojo, but I don't want to have multiple copies of dojo checked in, or have to reference each file in the project.
Use the "Add as link" feature of Visual Studio.
http://msdn.microsoft.com/en-us/library/vstudio/9f4t9t92(v=vs.100).aspx
. . .
I am also a Dojo user. You will want to learn to do Dojo builds, to reduce Dojo to just a few files, and host them on your server. In many cases, in lieu of that, with some tiny loss of efficiency for the first load (after that, caching takes care of things) using the one of the CDNs like google to access the Dojo files is also effective.
Depending on your particular circumstances, it may be better to put the files out on a server, and just reference them in your HTML templates. This is, for example, how we do all our internal Dojo applications in my organization--three developers use one set of Dojo files for all applications.
My team has been working with creating dashboards and drill-through reports. We've moved past our proof-of-concept phase and are now working to build the "production ready" reports. In our meetings it has been brought up that the overall styles for the reports should be changed from the Cognos defaults.
We became aware of Cognos's skin system. We saw that there was skinning for the portal and UI elements that are used within the report display and portal. This is not necessarily what we wanted. We ideally wanted to be able to change the portal to company branding AND change the way lists and crosstabs looked (as well as other elements of the actual report).
I was able to look at the page source generated for a report and saw that it is including styles from:
cognos\c10_64\webcontent\schemas
While poking around the webcontent directory I also found this path:
cognos\c10_64\webcontent\reportstyles
Both of these paths contain css files with similar names. The included styles for the report HTML point to the "schemas" directory, however my logical thinking self would like to believe that the "reportstyles" directory is used somewhere within the Cognos report display even though I have not seen it included in any page source I have viewed.
I have begun making my modifications to the css in the "schemas" path using a system of taking the included css file, copying the css out of it and placing it into a "xxx_system.css" file, and then including that file in the original css file.
This process works and we are able to see the changes, but we are still wondering if there is a better or "more correct" way of doing this. Can anyone elaborate on the best way to skin/style the actual reports?
My approach to customizing the UI is significantly different - imagine me coming into a company where they've been doing the same thing for 6+ years and I want to start changing everything around. It was met with some resistance, so I hope my experience can help you get started.
I come from a strong UI-based background and immediately wanted to contribute my knowledge to the reports we were designing. That required tact, as I wanted to show the value of a well-designed UI without shocking/scaring everyone that uses it (change adversity and the like). I handled this by working within the reports, not on the Cognos files themselves.
The minute you start working with the core files, whether they be CSS, Javascript, or CGI itself, there's an immediate and glaring risk that it will entirely break on upgrade. I got around this by creating HTML items in my reports and calling resources from there. For example, this HTML item is in virtually every header of my reports:
<link type="text/css" href="cognos8/common/css/ui-lightness/jquery-ui-1.8.5.custom.css" rel="Stylesheet" />
<link type="text/css" href="custom.css" rel="Stylesheet" />
<script type="text/javascript"
src="https://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
<script type="text/javascript"
src="https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.5/jquery-ui.min.js"></script>
<script type="text/javascript">
jQuery.noConflict();
jQuery(document).ready(function() {
}); // End Ready
</script>
So now I've got access to jQuery, the UI Framework, and everything else. I specify overrides in my custom.css and build my look from there. This might seem cumbersome, but IBM has a knack for upgrading major versions and completely wiping out naming conventions and functions, so if your CSS selector is off, it "defaults" to IBM's original style.
This is just how I've had to get around it and I'm not sure entirely that it's the best way. I've been working with what I have, which is no access to the server files or anything like that. Just consider this a super-safe approach.
I'm working with Cognos 10.1 now and getting ready for launch. The way I'm handling the installation, configuration and any tweaks is the an auto build/configure process that pulls data from a revision control system. This way even when upgrading I don't loose any customization and can easily merge in changes from the upgrade.
You can absolutely change the look and feel of crosstabs and lists using the support Cognos skinning system. I've done a complete look-and-feel overhaul of Cognos for a previous employer which including changing the way dynamic elements looked.
If you look at the default styles in the GlobalReportStyles.css, all of these styles can be over-ridden in custom CSS files in your skin. That method would be safer than modifying the GlobalReportStyles.css directly as a custom skin directory will not be modified by an upgrade but the global stylesheet surely will be.
Unfortunately, you can't be certain that any modifications you create via the skin facility will render exactly the same way from version to version. Cognos could rearrange the UI or tweak the general appearance enough to break your changes. However, this is the only way I know of to effectively create universal, automatic look and feel modifications to the default Cognos objects.
There's a lot of great information on MSDN dealing with creating Visual Studio templates. I've been specifically working through a Multi-Project Solution (http://msdn.microsoft.com/en-us/library/ms185308(VS.80,printer).aspx)
I have everything working in my template (4 projects + 2 Solution Folders - 1 for Tests, and 1 for Libraries that I'm referencing). I have no problem adding projects, or solution folders through the template, but I've hit a wall trying to add dll's and other resources that are not in a specific project, they are just solution level items.
Has anyone dealt with this before? Thanks,
I have been trying to do the same thing for a while now and have had no luck finding a native way to do it. The way I am doing it currently is having a custom project template that adds the items to the project and then through a VS Wizard associated with that template using convention to move the files to the solution level and removing them from the project level.
This hack might be 10 years late, but thought I'd add it anyway. Its less convoluted than creating a VS Wizard to drive the operation of adding solution level items.
Basically I add a dummy project to the multi-project solution template, named "_SharedFiles".
In the other projects that need links to any of these files, I update the [project].csproj to simply refer to the file in the shared files dummy project.
<Link Include="..\_SharedFiles\GlobalAssemblyInfo.cs" />