I'm trying to create external annotations for System.IO.StreamReader.ReadToEndAsync. I've been looking at other questions on the topic, and tried to decipher what to do from those, and from how already existing external annotations look.
Right now I have:
A file named 4.0.0.0.Annotations.xml, located in;
[user]\AppData\Local\JetBrains\Installations\ReSharperPlatformVs14\ExternalAnnotations\mscorlib
The contents of the annotation file is:
<?xml version="1.0" encoding="utf-8"?>
<assembly name="mscorlib, Version=4.0.0.0">
<member name="M:System.IO.StreamReader.ReadToEndAsync()">
<attribute ctor="M:JetBrains.Annotations.NotNullAttribute.#ctor" />
</member>
</assembly>
I want to convince the code inspection that ReadToEndAsync will not return null, but it doesn't seem to be working (still getting warnings). Tried different naming, restarted Visual Studio and stuff, but to no avail.
What am I doing wrong?
I didn't realize that there may be several ExternalAnnotations folders with the ReSharper installation. In my case, the solution was to move the mscorlib folder I created for the 4.0.0.0.Annotations.xml file to:
[user]\AppData\Local\JetBrains\Installations\
ReSharperPlatformVs14_000 \ExternalAnnotations
Also, the syntax for annotating a method without parameters does not seem to include parentheses, so I also removed those, changing name="M:System.IO.StreamReader.ReadToEndAsync()" to name="M:System.IO.StreamReader.ReadToEndAsync".
Related
I've gotten some weird effects lately, where sometimes when I deploy my CQ application via Maven to my local AEM Server, it would't update correctly.
E.g. when changing something in a dialog of a component, I have to delete the /app/myapp folder in CRX and deploy again to get changes to appear.
I'm also having a hard time reproducing the effect. It happens seemingly in random intervals.
Please check your filter.xml file. This descriptor should contain all the root paths for your application so most probably: /app/myapp, /etc/designs/myapp and maybe couple others.
For more information please check vault documentation (section using filters). This file is used by CQ package manager to install the content.
In previous CQ versions there was a behaviour that filters were almost ignored. Starting from CQ 5.6 if any content path does not match filter.xml regexps it won't be installed. This does not match exactly your issue but kindly check if updating filter.xml file helps.
Here is what I use for our project and has worked flawlessly on AEM6 but should also work perfectly on CQ 5.6. Replace "ourProject" with whatever is appropriate and let me know if you still have issues.
<?xml version="1.0" encoding="UTF-8"?>
<workspaceFilter version="1.0">
<filter root="/apps/ourProject">
<exclude pattern=".*install" />
</filter>
<filter root="/etc/ourProject"/>
<filter root="/etc/designs/ourProject" />
<filter root="/etc/widgets" />
<filter root="/etc/workflows" mode="update"/>
</workspaceFilter>
I've tried many different things now, none of which seem to work out as expected.
I would like to share an example config(or image or whatever) file with my library that someone would be able to use and derive from. I tried to default to just To do so I tried to include it in the nuget package via *.nuspec and via *.csproj. None of which worked.
For the *.nuspec part, I've tried this:
<file src="bin\$configuration$\example.mylib.config" target="lib\net45" />
<file src="bin\$configuration$\example.mylib.config" target="build" />
<file src="bin\$configuration$\example.mylib.config" target="bin" />
I've also tried this, but that only copies the file to the other projects sources, which is not what I want. I would like it to only show up in the output of the build.
<file src="bin\$configuration$\example.mylib.config" target="content" />
For the *.csproj part, I've tried to set the build action of the file to content, resource, embedded resource and None.
Is there a way at all?
Is there a way to tell nuget, take this file, and behave like the dll I'm providing needs this by it's side, wherever you build?
One thought might be to perform a config file transformation. Rather than just deploying a config file directly, you could modify the app.config or web.config on the project with a sample for the user to apply. Alternatively, as you mentioned in your comment, you could add in a Powershell script to perform the manipulations you were considering.
To deploy to different azure environments I modify the csdef as part of the compilation step to change the host headers. Doing so requires building the cspkg once for each environment instead of being able to reuse the cspkg and specify different configs for deployment.
I would like to instead modify the csdef file of a cspkg after it has been created, without recompiling. Is that possible, and if so how?
I've done something similar to what you're after to differentiate between test and live environments. First of all you need to create a new .csdef file that you want to use for your alternate settings. This needs to be the complete file as we're just going to swap it out with the original one. Now we need to add this to the cloud project. Right click on the cloud project and select unload project. Right click on it again and select Edit [Name of project]. There's a section that looks a bit like this:
<ItemGroup>
<ServiceConfiguration Include="ServiceConfiguration.Test.cscfg" />
<ServiceDefinition Include="ServiceDefinition.csdef" />
<ServiceConfiguration Include="ServiceConfiguration.cscfg" />
</ItemGroup>
Add a new ServiceDefinition item that points to your newly created file. Now find the following line:
<Import Project="$(CloudExtensionsDir)Microsoft.WindowsAzure.targets" />
Then add this code block, editing the TargeProfile check to be the build configuration you're wanting to use for your alternate and ensuring that it points to your new .csdef file
<Target Name="AfterResolveServiceModel">
<!-- This should be run after it has figured out which definition file to use
but before it's done anything with it. This is all a bit hard coded, but
basically it should remove everything from the SourceServiceDefinition
item and replace it with the one we want if this is a build for test-->
<ItemGroup>
<!-- This is an interesting way of saying remove everything that is in me from me-->
<SourceServiceDefinition Remove="#(SourceServiceDefinition)" />
<TargetServiceDefinition Remove="#(TargetServiceDefinition)" />
</ItemGroup>
<ItemGroup Condition="'$(TargetProfile)' == 'Test'">
<SourceServiceDefinition Include="ServiceDefinition.Test.csdef" />
</ItemGroup>
<ItemGroup Condition="'$(TargetProfile)' != 'Test'">
<SourceServiceDefinition Include="ServiceDefinition.csdef" />
</ItemGroup>
<ItemGroup>
<TargetServiceDefinition Include="#(SourceServiceDefinition->'%(RecursiveDirectory)%(Filename).build%(Extension)')" />
</ItemGroup>
<Message Text="Source Service Definition Changed To Be: #(SourceServiceDefinition)" />
</Target>
To go back to normal, right click on the project and select Reload Project. Now when you build your project, depending on which configuration you use, it will use different .csdef files. It's worth noting that the settings editor in is not aware of your second .csdef file so if you add any new settings through the GUI you will need to add them manually to this alternate version.
If you would want to just have a different CSDEF then you can do it easily by using CSPACK command prompt directly as below:
Open command windows and locate the folder where you have your CSDEF/CSCFG and CSX folder related to your Windows Azure Project
Create multiple CSDEF depend on your minor changes
Be sure to have Windows Azure SDK in path to launch CS* commands
USE CSPACK command and pass parameters to use different CSDEF and Output CSPKG file something similar to as below:
cspack <ProjectName>\ServiceDefinitionOne.csdef /out:ProjectNameSame.csx /out:ProjectOne.cspkg /_AddMoreParams
cspack <ProjectName>\ServiceDefinitionTwo.csdef /out:ProjectNameSame.csx /out:ProjectTwo.cspkg /_AddMoreParams
More about CSPACK: http://msdn.microsoft.com/en-us/library/windowsazure/gg432988.aspx
As far as I know, you can't easily modify the .cspkg after it is created. I guess you probably technically could as the .cspkg is a zip file that follows a certain structure.
The question I'd ask is why? If it is to modify settings like VM role size (since that's defined in the .csdef file), then I think you have a couple of alternative approaches:
Create a seperate Windows Azure deployment project (.csproj) for each variation. Yes, I realize this can be a pain, but it does allow the Visual Studio tooling to work well. The minor pain may be worth it to have the easier to use tool support.
Run a configuration file transformation as part of the build process. Similiar to a web.config transform.
Personally, I go with the different .csproj approach. Mostly because I'm not a config file transformation ninja . . . yet. ;) This was the path of least resistance and it worked pretty well so far.
I'm having trouble opening my main in my eclipse project. It keeps coming up with:
"content is not allowed in prolog"
I haven't altered my code or anything.
I have no idea what has gone wrong, anybody seen this before?
I had the same error and figured it out.
When I tried to create a new string resource, I tried to paste the new resource value on the "Android Resources" screen. To my surprise, the paste operation (using CTRL + V) does not work on that screen, and I tried it several times.
After that I started getting the error. When I switched from the "Android Resources" screen to the raw XML screen of the Strings.xml file, I noticed that all the text that I tried to paste was at the beginning of the file, like this:
Image content description. Image content description.<?xml version="1.0" encoding="utf-8"?>
<resources>
<string name="app_name">My App</string>
</resources>
And that was causing the error for me.
This error is generated during parsing of an XML document. Here is one writeup:
http://www.mkyong.com/java/sax-error-content-is-not-allowed-in-prolog/
You didn't provide sufficient information in your question to know which file might be corrupted, but search for xml files in your project and see if they look ok.
Restarting Eclipse and Cleaning the problem dint help.
I opened the .xml file in a XML editor and did a Validate on that error alone. this solved my problem. Hope this helps for people who still got the problem
Its most likely an encoding problem: (edit in notepad++ and select) encoding utf-8 -BOM
I had the same problem, It may be because of XML parser issue,
I restarted the eclipse it started working fine.
I also had the same error.Check your Xml files.There may be syntax error in xml files.
Having incorrect encoding information might cause this.
<?xml version="1.0" encoding="utf-16"?>
at the top of an ascii or utf-8 encoded file for example.
Yeah, I had the same, and the first line in strings.xml:
<?xml version="1.0" encoding="utf-8"?>
was marked with this error. Though I also didn't alter any code, yesterday, when I closed Eclipse, everything was fine, no errors (though some warnings were present, but that doesn't matter, I think)
All I did now is Selecting this line, Ctrl+X (Cut) it, Ctrl+S to save, Ctrl+V (Paste) it back and Ctrl+S again, and the error is gone. Not sure if it will work for everybody, but it did for me 8)
Check: that you have no any additional wrong text before in the beginning of file.
In my case I was seeing those error in java classes i.e. NOT XML and, the problem was related to a hidden file called .springBeans in the main project directory. I had a section "configs" and "autoconfigs" like:
java:org.DDDDDDDDDD.config.PersistenceConfig
java:org.DDDDDDDDDD.core.Application
When i moved everything to autoconfigs it all worked for me
In my case, server.xml got corrupted.
Go to pivotal/tomcat server location.
Path : base-instance\conf
File Name: server.xml
So i tried replacing below content in that file and it worked fine.
Sample content:-
<?xml version="1.0" encoding="UTF-8"?>
<Server port="${base.shutdown.port}" shutdown="SHUTDOWN">
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener"/>
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"/>
<Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"/>
<Listener className="com.springsource.tcserver.serviceability.deploy.TcContainerDeployer"/>
<Listener accessFile="${catalina.base}/conf/jmxremote.access" address="127.0.0.1" authenticate="true" className="com.springsource.tcserver.serviceability.rmi.JmxSocketListener" passwordFile="${catalina.base}/conf/jmxremote.password" port="${base.jmx.port}" useSSL="false"/>
<GlobalNamingResources>
<Resource auth="Container" description="User database that can be updated and saved" factory="org.apache.catalina.users.MemoryUserDatabaseFactory" name="UserDatabase" pathname="conf/tomcat-users.xml" type="org.apache.catalina.UserDatabase"/>
</GlobalNamingResources>
<Service name="Catalina">
<Executor maxThreads="300" minSpareThreads="50" name="tomcatThreadPool" namePrefix="tomcat-http--"/>
<Engine defaultHost="localhost" name="Catalina">
<Realm className="org.apache.catalina.realm.LockOutRealm">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>
</Realm>
<Host appBase="webapps" autoDeploy="true" deployOnStartup="true" deployXML="true" name="localhost" unpackWARs="true">
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" pattern="%h %l %u %t "%r" %s %b" prefix="localhost_access_log." suffix=".txt"/>
</Host>
</Engine>
<Connector acceptCount="100" connectionTimeout="20000" executor="tomcatThreadPool" maxKeepAliveRequests="15" port="${nio.http.port}" protocol="org.apache.coyote.http11.Http11NioProtocol" redirectPort="${nio.https.port}"/>
</Service>
</Server>
I had a similar issue and wanted to make a note, in case other had the same root cause that I did.
My issue was related to the xsi:schemaLocation. The url stated was no longer being served. Via googling, I got a copy of the actual xsd file, which I included locally then updated the reference. This solved my issue.
e.g. http://dozer.sourceforge.net/schema/beanmapping.xsd became beanmapping.xsd in the snippet below, after adding the .xsd file to the same folder.
<?xml version="1.0" encoding="UTF-8"?>
<mappings xmlns="http://dozer.sourceforge.net" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://dozer.sourceforge.net beanmapping.xsd">
i delete the c:/users/your_computer/appdata/.gradle/cache and it went go to normal
I fix it with a non - xml file by clearing the file in the text editor, save the empty file and paste it back. (CTRL+A, CTRL+X, CTRL+S, CTRL+V, CTRL+S)
I'm sure everyone has to deal with these situations, we check in our solution to source control and each dev machine will have its own resources for debugging, building and testing..
The most common being:
Web server (IIS)
Database (SQL)
The web server is easy to handle, each dev machine will have its own proj.user file to specify different debug information.
But connection strings for the app are stored in the web.config (which is under source control), ideally we don't want the web.config to be 'aware', so having to do config sections where we delegate them to other config files (not under sc) wouldn't be the best solution..
asp.net (.net?) already supports a model to have web.config inheritance, which would be an ideal scenario.. however this only works for directories.
It would be great if we could have
web.config <-- under version control
web.machine.config <-- not under version control
Of course I'm open for better suggestions of how people solve this problem.
Like.. maybe having:
web.base.config <-- under version control
web.machine.config <-- not under version control
And having a build script that creates a web.config by merging them?
Thanks in advance,
Stephen.
edit
Looks like the next vs may have a way to handle this:
http://blogs.msdn.com/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx
edit edit
Possibly do'able with xml mass update today:
http://blogs.microsoft.co.il/blogs/dorony/archive/2008/01/18/easy-configuration-deployment-with-msbuild-and-the-xmlmassupdate-task.aspx
edit edit edit
Well its certainly possible to do with a simple xslt build task and a small transform that copied everything and intercepts certain properties.. just tried a proof of concept and this will save us lots of frustration, but the transformation file may be more than people are willing to accept.
Basically we store a Web.base.config in version control, and run it through the transform to generate the Web.config on a build event.
Seems like vs2010 will really help in terms of having a much more friendly version of this.
One approach that I sometimes use is to break out environment-specific section into separate config file, that are usually excluded from deployment (except for the first time or if their structure change):
Example for connection strings:
In web.config:
<connectionStrings configSource="connections.config"></connectionStrings>
The connections.config file (that is typically not included in the deployment; so it is unchanged):
<?xml version="1.0"?>
<connectionStrings>
<add name="connectionName" connectionString="[connection string goes here]"/>
</connectionStrings>
Like that we have created an "incapsulation" of the information, and can easily deal with issues like source control, deployment and such of that information.
Whilst there are certainly plenty of solutions, none of them really give you a huge amount of control over the generated configuration, one solution that I noted in my edit where you get a huge amount of control but with the overhead of having to write an xslt file, was using an xslt build task to use the template web.config/app.config from source control (which I personally name web.base.config/app.base.config), and use an xslt file to transform the version controlled config file at build time, and generate a web.config/app.config.
Here is an example of an xslt build task (although you may want to write it to your own coding standards), and an example of a mundane xslt transform that will change the value of a connection string and copy everything else in the config:
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" exclude-result-prefixes="msxsl">
<xsl:output method="xml" indent="yes"/>
<!-- Copy all. -->
<xsl:template match="#* | node()">
<xsl:copy>
<xsl:apply-templates select="#* | node()"/>
</xsl:copy>
</xsl:template>
<!-- Swap connection string. -->
<xsl:template match="/configuration/connectionStrings/add[#name='my_connection_string_name']">
<xsl:copy>
<xsl:apply-templates select="#* | node()"/>
<xsl:attribute name="connectionString">my replacement connection string value</xsl:attribute>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
This is a mediocre example, but you can imagine you can completely transform entire sections where you previously would struggle with an inheritance based scenario.
VS 2010 will provide you with a lot of control to manage web.config files for various configurations... Please check out.
The configuration of an application can be split into two categories.
Application specific
Deployment specific
Application specific configuration includes things like caching implementation, business rules implementation, and will apply to every deployment of the application. This should go into the web.config file that is part of the application directory structure and is checked into source control.
Deployment specific configuration includes things like connection strings, timeout periods, etc, and may differ from one deployment to another. This should be entered as part of the configuration of the IIS instance that is involved in the deployment and preserved by whatever backup strategy is in place for the machine in question.
As far as I can tell, this is exactly what the hierarchical nature of the web.config files was designed to handle.
The advantages of such an arrangement are...
No need to worry about which developer's version of the settings end up in source control, because none of them do.
Every deployment uses the same binary, so deployment issues are more likely to involve the deployment configuration.
Subsequent deployments should need no deployment specific configuration changes, because they are already in place.
We don't store environment settings in the web.config.
They're stored in a database.
This enables us to do xcopy deploys, and to store the web.config file in our version control system.
Access to the database is via one registry key.
What you're describing sounds a lot like using a Machine.config file to store connection strings. I haven't seen this mentioned yet, so have you tried it? It looks like you can use a global Web.config that sits beside your Machine.config as well.
A few links:
ASP.NET Configuration File Hierarchy and Inheritance
Difference between Web.config and Machine.config