Search Results

Search found 3604 results on 145 pages for 'sfdc deployment'.

Page 1/145 | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

  • Deployment Options for AutoVue 20.0 Users

    - by celine.beck
    AutoVue release 20.0 boasts a brand new architecture. As part of this product rearchitecture, AutoVue can now be deployed either as a desktop deployment to serve the needs of individual users in their personal productivity; or in a Client / Server deployment for those that require connections to enterprise applications / back-end systems. The most common question that we hear from our customers about this new architecture is the following: "Is AutoVue Desktop Version still part of release 20.0 and if so, what is the difference between AutoVue Desktop Version and the Desktop deployment of AutoVue release 20.0?" A detailed answer to these questions is provided in a very complete article entitled Understanding Deployment Options for AutoVue 19.3 Desktop Version users upgrading to AutoVue 20.0 (note 1058254.1) which was posted on My Oracle Support. Is AutoVue Desktop Version still part of AutoVue 20.0? Yes, AutoVue Desktop Version 20.0 is still available to customers and partners, as a maintenance release of AutoVue 19.3. As such, it will not contain any of the new capabilities featured in AutoVue release 20.0. All format enhancements and new format support have been added to release 20.0 Desktop Version though. What is the different between AutoVue Desktop Version 20.0 and the Desktop Deployment of AutoVue release 20.0? AutoVue 20.0 Desktop deployment works like the AutoVue Desktop version. It is installed as a standalone product on each user's machine and runs a local instance of AutoVue. The AutoVue 20.0 Desktop deployment includes all new features, formats and performance enhancements included in release 20.0 (walkthrough capability, improved compare, ...) What deployment options are available to AutoVue 19.3 Desktop Version customers? AutoVue Desktop Version users can evolve at their own pace to the new AutoVue platform. With release 20.0, customers can opt to: Option 1: Stay on AutoVue Desktop Version 20.0 Option 2: Migrate to AutoVue and select the desktop deployment method Option 3: Migrate to AutoVue and select the Client/Server deployment method What is the Client / Server deployment of AutoVue 20.0? The Client/Server deployment has AutoVue installed on a server, to which local client machines connect to access and view documents. AutoVue 20.0 Client Server Deployment allows users to leverage the new online/offline capabilities in release 20.0 and easily switch between online and offline modes of operation. With the Client/Server deployment, customers also get a complete, open and standards-based set of integration tools that allows them to tie AutoVue to any enterprise applications to provide users with a consistent view of data and business objects and expand workflow automation to document-based processes. Related articles: AutoVue Release 20.0 Now Available, New Walkthrough Capability in AutoVue 20.0, Watch the AutoVue 20.0 Release Webcast, April 27 at 12pm EST

    Read the article

  • Salesforce deployment guideline using Sandbox

    - by ybbest
    Create Deployment connection Enable the inbound change set settings on the destination Environment you would like to deploy the solution to. Enable the outbound change set settings on the source Environment where you package your application. The best practice is to Package everything in the changeset and salesforce will only deploy the change into your destination environment. If you only package the change, you could miss some of the changes. You can clone the change set on the source destination however the initial packaging takes some time as you need to go through everything and select the components manually. After the change set is packaged, you need to upload the chagneset so that destination environment can see the change set in its incoming change set list. Click Validate the change set before deployment. References: Development Lifecycle Guide Change Sets Best Practices

    Read the article

  • Associating File Types with AutoVue Desktop Deployment

    - by [email protected]
    Windows users take for granted that when they double click on a document or design, that it will open up in its application automatically. One of the questions I'm commonly asked is "How can I get the same behavior with AutoVue Desktop Deployment?". It's pretty easy, but there are a few tricks to doing it. Step 1: Download new jvue_direct.bat and icon The first thing you'll need to do is download a slightly modified version of jvue_direct.bat. You can find it here (Document 1075784.1) on Oracle's Support Portal. You also want to download the AV.ico file. This is the icon that will be used for all file types associated with AutoVue. Place both of these files in your <AutoVueInstallDirectory>\bin directory. Step 2: Associate File Types With AutoVue There are two ways to do this. You can do this through the Windows user interface, or you can set up a batch file to do this. Associating File Types Through Windows The way most people associate file types to an application is using the Windows user interface. You've probably tried to open a file type that Windows doesn't recognize and seen this window pop up: Although you can use this dialog to associate that file type with AutoVue, I don't recommend it. I much prefer using a batch file to associate file types with AutoVue. Associating File Types Using A Batch File There are a few good reasons to associate file types using a batch file instead of using the pop-up dialog method: If you have several file types to associate with AutoVue, it's much easier to use a batch file to do them all at once. Doing it through the Windows user interface requires having files of each type available. Using a batch file doesn't require having the files you're associating. Associating file types through the dialog may work well for one person, but what if you're an administrator doing an enterprise wide deployment of AutoVue Desktop Deployment for several hundred users? You don't want to do this manually for each user. You can have one simple batch file that's run on each user's PC to set up all the file types. You can easily associate an icon with the file types you're opening with AutoVue. To use the batch file method follow these steps: Create a file called filetype.bat using a text editor and copy and paste the following into it: @assoc .dwg=AVFile @assoc .jpg=AVFile @assoc .doc=AVFile @ftype AVFile="%~dp0jvue_direct.bat" "%%1" @reg add HKEY_CLASSES_ROOT\AVFile\DefaultIcon /v "" /f /d "%~dp0AV.ico" Change the lines starting with @assoc. Each of these lines associates a file extension with AutoVue. You can have as many @assoc lines as you want. Save this file in your <AutoVueInstallDirectory>\bin directory. Double click this file, or run it from a command prompt. Restart Windows to get the icons to show up. How Does This Work? The first three lines are creating a file type called AVFile. We are associating the extensions .dwg, .jpg, and .doc with this file type. You will want to change these lines when creating your own batch file. For example, to associate Microstation designs, which have extension .dgn, you should delete the @assoc lines above and add the line: @assoc .dgn=AVfile The line beginning with @ftype tells Windows that all AVFile type files should be opened using AutoVue Desktop Deployment. The final line associates the AutoVue icon with these file types. You may need to restart Windows to see the new icons. Warning: One Size Doesn't Fit All When deciding which file types should be associated with AutoVue, remember that there are different types of users using it. Your engineers may be pretty surprised to find that after installing AutoVue, double clicking their .dwg file opens up AutoVue instead of AutoCAD. If you have more than one type of AutoVue user, make sure you've considered what file types each user group will and will not want to be associated with AutoVue. If necessary, create a separate file association batch file for each user type. So that's it. In two simple steps you can double click your favorite designs and have them open automatically in AutoVue Desktop Deployment. I'd love to hear how are you using AutoVue Desktop Deployment. What other deployment tips would you be interested in learning about?

    Read the article

  • Designing a Content-Based ETL Process with .NET and SFDC

    - by Patrick
    As my firm makes the transition to using SFDC as our main operational system, we've spun together a couple of SFDC portals where we can post customer-specific documents to be viewed at will. As such, we've had the need for pseudo-ETL applications to be implemented that are able to extract metadata from the documents our analysts generate internally (most are industry-standard PDFs, XML, or MS Office formats) and place in networked "queue" folders. From there, our applications scoop of the queued documents and upload them to the appropriate SFDC CRM Content Library along with some select pieces of metadata. I've mostly used DbAmp to broker communication with SFDC (DbAmp is a Linked Server provider that allows you to use SQL conventions to interact with your SFDC Org data). I've been able to create [console] applications in C# that work pretty well, and they're usually structured something like this: static void Main() { // Load parameters from app.config. // Get documents from queue. var files = someInterface.GetFiles(someFilterOrRegexPattern); foreach (var file in files) { // Extract metadata from the file. // Validate some attributes of the file; add any validation errors to an in-memory // structure (e.g. List<ValidationErrors>). if (isValid) { var fileData = File.ReadAllBytes(file); // Upload using some wrapper for an ORM or DAL someInterface.Upload(fileData, meta.Param1, meta.Param2, ...); } else { // Bounce the file } } // Report any validation errors (via message bus or SMTP or some such). } And that's pretty much it. Most of the time I wrap all these operations in a "Worker" class that takes the needed interfaces as constructor parameters. This approach has worked reasonably well, but I just get this feeling in my gut that there's something awful about it and would love some feedback. Is writing an ETL process as a C# Console app a bad idea? I'm also wondering if there are some design patterns that would be useful in this scenario that I'm clearly overlooking. Thanks in advance!

    Read the article

  • Designing Content-Based ETL Process with .NET and SFDC

    - by Patrick
    As my firm makes the transition to using SFDC as our main operational system, we've spun together a couple of SFDC portals where we can post customer-specific documents to be viewed at will. As such, we've had the need for pseudo-ETL applications to be implemented that are able to extract metadata from the documents our analysts generate internally (most are industry-standard PDFs, XML, or MS Office formats) and place in networked "queue" folders. From there, our applications scoop of the queued documents and upload them to the appropriate SFDC CRM Content Library along with some select pieces of metadata. I've mostly used DbAmp to broker communication with SFDC (DbAmp is a Linked Server provider that allows you to use SQL conventions to interact with your SFDC Org data). I've been able to create [console] applications in C# that work pretty well, and they're usually structured something like this: static void Main() { // Load parameters from app.config. // Get documents from queue. var files = someInterface.GetFiles(someFilterOrRegexPattern); foreach (var file in files) { // Extract metadata from the file. // Validate some attributes of the file; add any validation errors to an in-memory // structure (e.g. List<ValidationErrors>). if (isValid) { // Upload using some wrapper for an ORM an someInterface.Upload(meta.Param1, meta.Param2, ...); } else { // Bounce the file } } // Report any validation errors (via message bus or SMTP or some such). } And that's pretty much it. Most of the time I wrap all these operations in a "Worker" class that takes the needed interfaces as constructor parameters. This approach has worked reasonably well, but I just get this feeling in my gut that there's something awful about it and would love some feedback. Is writing an ETL process as a C# Console app a bad idea? I'm also wondering if there are some design patterns that would be useful in this scenario that I'm clearly overlooking. Thanks in advance!

    Read the article

  • Just Another Web Service (JAWS) vs SOA

    Over the last few years SOA has been a hot topic lending it to be abused by many that have no understanding of the concept. In my opinion, one of the largest issues facing SOA is the lack of understanding and experience implementing SOA by business and IT alike. I just recently deployed a new web services that is called by multiple service clients. Would you call this SOA because it is a web service that can be called by any requesting client? In my opinion, this is not SOA; instead it is Just Another Web Service (JAWS).  Just because a company creates a web service does not mean that they are using SOA, in fact it only means that they are using a web service. SOA is an architectural style that focuses on the design of systems based on the consumer and providers thorough the use of contracts.  With this approach SOA needs to be applied for the top down in order for it to reach its full potential. In the case of the web service, the service is just a small part of the entire system that is reusable and has the flexibility to change. In order for a company in this case to move towards SOA then they need to define business processes that can be shared through the use of reusable software and loose coupling. Once the company’s thought and development process change to address changes in this manner they can start to become more SOA.

    Read the article

  • Automated Deployment of Windows Application

    - by Phillip Roux
    Our development team are looking to automate our application deployment on to multiple servers. We need to control multiple windows servers at once (Stopping Database server & Web Server). We have a ASP.NET project, database upgrade scripts, reports and various Windows services that potentially need to be updated during deployment. Currently we use Jenkins as our CI server to run our unit tests. If something goes wrong in the deployment process, we would like the ability to roll back. What tools are recommended to automate our deployment process?

    Read the article

  • Deploy ASP.NET Web Applications with Web Deployment Projects

    - by Ben Griswold
    One may quickly build and deploy an ASP.NET web application via the Publish option in Visual Studio.  This option works great for most simple deployment scenarios but it won’t always cut it.  Let’s say you need to automate your deployments. Or you have environment-specific configuration settings. Or you need to execute pre/post build operations when you do your builds.  If so, you should consider using Web Deployment Projects. The Web Deployment Project type doesn’t come out-of-the-box with Visual Studio 2008.  You’ll need to Download Visual Studio® 2008 Web Deployment Projects – RTW and install if you want to follow along with this tutorial. I’ve created a shiny new ASP.NET MVC project.  Web Deployment Projects work with websites, web applications and MVC projects so feel free to go with any web project type you’d like.  Once your web application is in place, it’s time to add the Web Deployment project.  You can hunt and peck around the File > New > New Project… dialogue as long as you’d like, but you aren’t going to find what you need.  Instead, select the web project and then choose the “Add Web Deployment Project…” hiding behind the Build menu option. I prefer to name my projects based on the environment in which I plan to deploy.  In this case, I’ll be rolling to the QA machine. Don’t expect too much to happen at this point.  A seemingly empty project with a funny icon will be added to your solution.  That’s it. I want to take a minute and talk about configuration settings before we continue.  Some of the common settings which might change from environment to environment are appSettings, connectionStrings and mailSettings.  Here’s a look at my updated web.config: <appSettings>   <add key="MvcApplication293.Url" value="http://localhost:50596/" />     </appSettings> <connectionStrings>   <add name="ApplicationServices"        connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true"        providerName="System.Data.SqlClient"/> </connectionStrings>   <system.net>   <mailSettings>     <smtp from="[email protected]">         <network host="server.com" userName="username" password="password" port="587" defaultCredentials="false"/>     </smtp>   </mailSettings> </system.net> I want to update these values prior to deploying to the QA environment.  There are variations to this approach, but I like to maintain environment-specific settings for each of the web.config sections in the Config/[Environment] project folders.  I’ve provided a screenshot of the QA environment settings below. It may be obvious what one should include in each of the three files.  Basically, it is a copy of the associated web.config section with updated setting values.  For example, the AppSettings.config file may include a reference to the QA web url, the DB.config would include the QA database server and login information and the StmpSettings.config would include a QA Stmp server and user information. <?xml version="1.0" encoding="utf-8" ?> <appSettings>   <add key="MvcApplication293.Url" value="http://qa.MvcApplicatinon293.com/" /> </appSettings> AppSettings.config  <?xml version="1.0" encoding="utf-8" ?> <connectionStrings>   <add name="ApplicationServices"        connectionString="server=QAServer;integrated security=SSPI;database=MvcApplication293"        providerName="System.Data.SqlClient"/>   </connectionStrings> Db.config  <?xml version="1.0" encoding="utf-8" ?> <smtp from="[email protected]">     <network host="qaserver.com" userName="qausername" password="qapassword" port="587" defaultCredentials="false"/> </smtp> SmtpSettings.config  I think our web project is ready to deploy.  Now, it’s time to concentrate on the Web Deployment Project itself.  Right-click on the project file and open the Property Pages. The first thing to call out is the Configuration dropdown.  I only deploy a project which is built in Release Mode so I only setup the Web Deployment Project for this mode.  (This is when you change the Configuration selection to “Release.”)  I typically keep the Output Folder default value – .\Release\.  When the application is built, all artifacts will be dropped in the .\Release\ folder relative to the Web Deployment Project root.  The final option may be up for some debate.  I like to roll out updatable websites so I select the “Allow this precompiled site to be updatable” option.  I really do like to follow standard SDLC processes when I release my software but there are those times when you just have to make a hotfix to production and I like to keep this option open if need be.  If you are strongly opposed to this idea, please, by all means, don’t check the box. The next tab is boring.  I don’t like to deploy a crazy number of DLLs so I merge all outputs to a single assembly.  Again, you may have another option and feel free to change this selection if you so wish. If you follow my lead, take care when choosing a single assembly name.  The Assembly Name can not be the same as the website or any other project in your solution otherwise you’ll receive a circular reference build error.  In other words, I can’t name the assembly MvcApplication293 or my output window would start yelling at me. Remember when we called out our QA configuration files?  Click on the Deployment tab and you’ll see how where going to use them.  Notice the Web.config file section replacements value.  All this does is swap called out web.config sections with the content of the Config\QA\* files.  You can reduce or extend this list as you deem fit.  Did you see the “Use external configuration source file” option?  You know how you can point any of your web.config sections to an external file via the configSource attribute?  This option allows you to leverage that technique and instead of replacing the content of the sections, you will replace the configSource attribute value instead. <appSettings configSource="Config\QA\AppSettings.config" /> Go ahead and Apply your changes.  I’d like to take a look at the project file we just updated.  Right-click on the Web Deployment Project and select “Open Project File.” One of the first configuration blocks reflects core Release build settings.  There are a couple of points I’d like to call out here: DebugSymbols=false ensures the compilation debug attribute in your web.config is flipped to false as part of build process.  There’s some crumby (more likely old) documentation which implies you need a ToggleDebugCompilation task to make this happen.  Nope. Just make sure the DebugSymbols is set to false.  EnableUpdateable implies a single dll for the web application rather than a dll for each object and and empty view file. I think updatable applications are cleaner and include the benefit (or risk based on your perspective) that portions of the application can be updated directly on the server.  I called this out earlier but I wanted to reiterate. <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">     <DebugSymbols>false</DebugSymbols>     <OutputPath>.\Release</OutputPath>     <EnableUpdateable>true</EnableUpdateable>     <UseMerge>true</UseMerge>     <SingleAssemblyName>MvcApplication293</SingleAssemblyName>     <DeleteAppCodeCompiledFiles>true</DeleteAppCodeCompiledFiles>     <UseWebConfigReplacement>true</UseWebConfigReplacement>     <ValidateWebConfigReplacement>true</ValidateWebConfigReplacement>     <DeleteAppDataFolder>true</DeleteAppDataFolder>   </PropertyGroup> The next section is self-explanatory.  The content merely reflects the replacement value you provided via the Property Pages. <ItemGroup Condition="'$(Configuration)|$(Platform)' == 'Release|AnyCPU'">     <WebConfigReplacementFiles Include="Config\QA\AppSettings.config">       <Section>appSettings</Section>     </WebConfigReplacementFiles>     <WebConfigReplacementFiles Include="Config\QA\Db.config">       <Section>connectionStrings</Section>     </WebConfigReplacementFiles>     <WebConfigReplacementFiles Include="Config\QA\SmtpSettings.config">       <Section>system.net/mailSettings/smtp</Section>     </WebConfigReplacementFiles>   </ItemGroup> You’ll want to extend the ItemGroup section to include the files you wish to exclude from the build.  The sample ExcludeFromBuild nodes exclude all obj, svn, csproj, user, pdb artifacts from the build. Enough though they files aren’t included in your web project, you’ll need to exclude them or they’ll show up along with required deployment artifacts.  <ItemGroup Condition="'$(Configuration)|$(Platform)' == 'Release|AnyCPU'">     <WebConfigReplacementFiles Include="Config\QA\AppSettings.config">       <Section>appSettings</Section>     </WebConfigReplacementFiles>     <WebConfigReplacementFiles Include="Config\QA\Db.config">       <Section>connectionStrings</Section>     </WebConfigReplacementFiles>     <WebConfigReplacementFiles Include="Config\QA\SmtpSettings.config">       <Section>system.net/mailSettings/smtp</Section>     </WebConfigReplacementFiles>     <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\obj\**\*.*" />     <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\**\.svn\**\*.*" />     <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\**\.svn\**\*" />     <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\**\*.csproj" />     <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\**\*.user" />     <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\bin\*.pdb" />     <ExcludeFromBuild Include="$(SourceWebPhysicalPath)\Notes.txt" />   </ItemGroup> Pre/post build and Pre/post merge tasks are added to the final code block.  By default, your project file should look like the following – a completely commented out section. <!– To modify your build process, add your task inside one of        the targets below and uncomment it. Other similar extension        points exist, see Microsoft.WebDeployment.targets.   <Target Name="BeforeBuild">   </Target>   <Target Name="BeforeMerge">   </Target>   <Target Name="AfterMerge">   </Target>   <Target Name="AfterBuild">   </Target>   –> Update the section to remove all temporary Config folders and files after the build.  <!– To modify your build process, add your task inside one of        the targets below and uncomment it. Other similar extension        points exist, see Microsoft.WebDeployment.targets.     <Target Name="BeforeMerge">   </Target>   <Target Name="AfterMerge">   </Target>     <Target Name="BeforeBuild">      </Target>       –>   <Target Name="AfterBuild">     <!– WebConfigReplacement requires the Config files. Remove after build. –>     <RemoveDir Directories="$(OutputPath)\Config" />   </Target> That’s it for setup.  Save the project file, flip the solution to Release Mode and build.  If there’s an issue, consult the Output window for details.  If all went well, you will find your deployment artifacts in your Web Deployment Project folder like so. Both the code source and published application will be there. Inside the Release folder you will find your “published files” and you’ll notice the Config folder is no where to be found.  In the Source folder, all project files are found with the exception of the items which were excluded from the build. I’ll wrap up this tutorial by calling out a little Web Deployment pet peeve of mine: there doesn’t appear to be a way to add an existing web deployment project to a solution.  The best I can come up with is create a new web deployment project and then copy and paste the contents of the existing project file into the new project file.  It’s not a big deal but it bugs me. Download the Solution

    Read the article

  • Java Deployment and Configuration (1.6.0_21)

    - by user125137
    Sofware: Java Runtime Environment 1.6.0_21 OS: Windows XP Professional 32-Bit, SP3 Situation: a new piece of web based software is being deployed this week and prior to this all the company desktops need to be set up to meet the requirements of this software. One of these requirements is JRE 1.6.0_21. I have successfully scripted the removal of all other Java versions and the installation of the required version, however I cannot get it configured properly. One of the requirements is that the Java console be set to disabled - if it is not it can cause an issue with a particular function. I have pushed out a deployment.config and deployment.properties but the console just will not disable itself.. I know the config is being read correctly because the update tab is being correctly disabled and removed. deployment.config: deployment.system.config=file\:C\:/WINDOWS/Sun/Java/Deployment/deployment.properties deployment.system.config.mandatory=true deployment.properties: #deployment.properties #Fri Jun 15 09:34:31 EST 2012 deployment.version=6.0 deployment.console.startup.mode=DISABLE deployment.javaws.autodownload=NEVER deployment.javaws.autodownload.locked= There is no change if I set the console to ENABLE either - it remains on the default of hidden. I'm sure I can disable the console with a registry change of some form but my preference is to have it done via the deployment files as it gives the option of centralising the properties file to a network share if we wish. If anyone has any suggestions it would be appreciated.

    Read the article

  • Website deployment - managing uploaded content?

    - by Legion
    I'm a programmer by trade, "server administrator" by company necessity. We're looking at dumping the old painful "update site by FTP upload" style of deployment. Having the webserver check out the latest code base from version control into a folder and having a "current" symlink point to the latest checkout (allowing for easily stepping back to an older version by changing the symlink) seems to be the way we want to go. But I have a question: what's a good practice for dealing with user-uploaded content? This stuff isn't in version control. I have a couple of ideas for dealing with this, but what is the smart, accepted practice?

    Read the article

  • Website deployment - managing user-uploaded content?

    - by Legion
    I'm a programmer by trade, "server administrator" by company necessity. We're looking at dumping the old painful "update site by FTP upload" style of deployment. Having the webserver check out the latest code base from version control into a folder and having a "current" symlink point to the latest checkout (allowing for easily stepping back to an older version by changing the symlink) seems to be the way we want to go. But I have a question: what's a good practice for dealing with user-uploaded content? This stuff isn't in version control. I have a couple of ideas for dealing with this, but what is the smart, accepted practice?

    Read the article

  • ClickOnce manifest problem

    - by TWith2Sugars
    We are currently deploying a WPF 4 app via click once and there is a scenario when the installation fails. If the user does not have .Net 4.0 Full install and attempts to install our app the framework installs fine but the app fails to install. If we re-run the installation again the app installs fine. Here is a copy of the log: PLATFORM VERSION INFO Windows : 6.1.7600.0 (Win32NT) Common Language Runtime : 2.0.50727.4927 System.Deployment.dll : 2.0.50727.4927 (NetFXspW7.050727-4900) mscorwks.dll : 2.0.50727.4927 (NetFXspW7.050727-4900) dfdll.dll : 2.0.50727.4927 (NetFXspW7.050727-4900) dfshim.dll : 4.0.31106.0 (Main.031106-0000) SOURCES Deployment url : [URL REMOVED] Server : Apache/2.0.54 Application url : [URL REMOVED] Server : Apache/2.0.54 IDENTITIES Deployment Identity : Graphicly.App.application, Version=0.3.2.0, Culture=neutral, PublicKeyToken=c982228345371fbc, processorArchitecture=msil Application Identity : Graphicly.App.exe, Version=0.3.2.0, Culture=neutral, PublicKeyToken=c982228345371fbc, processorArchitecture=msil, type=win32 APPLICATION SUMMARY * Installable application. ERROR SUMMARY Below is a summary of the errors, details of these errors are listed later in the log. * Dependency Graphicly.WCFClient.dll cannot be processed for patching. Following failure messages were detected: + Exception occurred loading manifest from file Graphicly.WCFClient.dll: the manifest may not be valid or the file could not be opened. + Cannot load internal manifest from component file. * Dependency Microsoft.Surface.Presentation.Design.dll cannot be processed for patching. Following failure messages were detected: + Exception occurred loading manifest from file Microsoft.Surface.Presentation.Design.dll: the manifest may not be valid or the file could not be opened. + Cannot load internal manifest from component file. * Dependency GalaSoft.MvvmLight.WPF4.dll cannot be processed for patching. Following failure messages were detected: + Exception occurred loading manifest from file GalaSoft.MvvmLight.WPF4.dll: the manifest may not be valid or the file could not be opened. + Cannot load internal manifest from component file. * Dependency Graphicly.Infrastructure.dll cannot be processed for patching. Following failure messages were detected: + Exception occurred loading manifest from file Graphicly.Infrastructure.dll: the manifest may not be valid or the file could not be opened. + Cannot load internal manifest from component file. * Dependency Graphicly.AutoUpdater.dll cannot be processed for patching. Following failure messages were detected: + Exception occurred loading manifest from file Graphicly.AutoUpdater.dll: the manifest may not be valid or the file could not be opened. + Cannot load internal manifest from component file. * Dependency System.Windows.Interactivity.dll cannot be processed for patching. Following failure messages were detected: + Exception occurred loading manifest from file System.Windows.Interactivity.dll: the manifest may not be valid or the file could not be opened. + Cannot load internal manifest from component file. * Dependency Microsoft.Surface.Presentation.dll cannot be processed for patching. Following failure messages were detected: + Exception occurred loading manifest from file Microsoft.Surface.Presentation.dll: the manifest may not be valid or the file could not be opened. + Cannot load internal manifest from component file. * Dependency Graphicly.Fonts.dll cannot be processed for patching. Following failure messages were detected: + Exception occurred loading manifest from file Graphicly.Fonts.dll: the manifest may not be valid or the file could not be opened. + Cannot load internal manifest from component file. * Dependency Graphicly.Reader.dll cannot be processed for patching. Following failure messages were detected: + Exception occurred loading manifest from file Graphicly.Reader.dll: the manifest may not be valid or the file could not be opened. + Cannot load internal manifest from component file. * Dependency Microsoft.Surface.Presentation.Generic.dll cannot be processed for patching. Following failure messages were detected: + Exception occurred loading manifest from file Microsoft.Surface.Presentation.Generic.dll: the manifest may not be valid or the file could not be opened. + Cannot load internal manifest from component file. * Dependency Graphicly.Controls.dll cannot be processed for patching. Following failure messages were detected: + Exception occurred loading manifest from file Graphicly.Controls.dll: the manifest may not be valid or the file could not be opened. + Cannot load internal manifest from component file. * Dependency Graphicly.SocialNetwork.dll cannot be processed for patching. Following failure messages were detected: + Exception occurred loading manifest from file Graphicly.SocialNetwork.dll: the manifest may not be valid or the file could not be opened. + Cannot load internal manifest from component file. * Dependency Graphicly.Archive.dll cannot be processed for patching. Following failure messages were detected: + Exception occurred loading manifest from file Graphicly.Archive.dll: the manifest may not be valid or the file could not be opened. + Cannot load internal manifest from component file. * Dependency Graphicly.App.exe cannot be processed for patching. Following failure messages were detected: + Exception occurred loading manifest from file Graphicly.App.exe: the manifest may not be valid or the file could not be opened. + Cannot load internal manifest from component file. * Dependency GalaSoft.MvvmLight.Extras.WPF4.dll cannot be processed for patching. Following failure messages were detected: + Exception occurred loading manifest from file GalaSoft.MvvmLight.Extras.WPF4.dll: the manifest may not be valid or the file could not be opened. + Cannot load internal manifest from component file. * Activation of [URL REMOVED] resulted in exception. Following failure messages were detected: + Exception occurred loading manifest from file GalaSoft.MvvmLight.Extras.WPF4.dll: the manifest may not be valid or the file could not be opened. + Cannot load internal manifest from component file. COMPONENT STORE TRANSACTION FAILURE SUMMARY No transaction error was detected. WARNINGS * The file named Microsoft.Windows.Design.Extensibility.dll does not have a hash specified in the manifest. Hash validation will be ignored. * The file named Ionic.Zip.Reduced.dll does not have a hash specified in the manifest. Hash validation will be ignored. * The file named Newtonsoft.Json.dll does not have a hash specified in the manifest. Hash validation will be ignored. * The file named Microsoft.WindowsAzure.StorageClient.dll does not have a hash specified in the manifest. Hash validation will be ignored. * The file named Dimebrain.TweetSharp.dll does not have a hash specified in the manifest. Hash validation will be ignored. * The file named Microsoft.Windows.Design.Interaction.dll does not have a hash specified in the manifest. Hash validation will be ignored. * The file named HtmlAgilityPack.dll does not have a hash specified in the manifest. Hash validation will be ignored. * The file named Facebook.dll does not have a hash specified in the manifest. Hash validation will be ignored. OPERATION PROGRESS STATUS * [20/05/2010 09:17:33] : Activation of [URL REMOVED] has started. * [20/05/2010 09:17:38] : Processing of deployment manifest has successfully completed. * [20/05/2010 09:17:38] : Installation of the application has started. * [20/05/2010 09:17:39] : Processing of application manifest has successfully completed. * [20/05/2010 09:17:40] : Request of trust and detection of platform is complete. ERROR DETAILS Following errors were detected during this operation. * [20/05/2010 09:17:40] System.Deployment.Application.InvalidDeploymentException (ManifestLoad) - Exception occurred loading manifest from file Graphicly.WCFClient.dll: the manifest may not be valid or the file could not be opened. - Source: System.Deployment - Stack trace: at System.Deployment.Application.Manifest.AssemblyManifest.ManifestLoadExceptionHelper(Exception exception, String filePath) at System.Deployment.Application.Manifest.AssemblyManifest.LoadFromInternalManifestFile(String filePath) at System.Deployment.Application.FileDownloader.AddFilesInHashtable(Hashtable hashtable, AssemblyManifest applicationManifest, String applicationFolder) --- Inner Exception --- System.Deployment.Application.DeploymentException (InvalidManifest) - Cannot load internal manifest from component file. - Source: - Stack trace: * [20/05/2010 09:17:40] System.Deployment.Application.InvalidDeploymentException (ManifestLoad) - Exception occurred loading manifest from file Microsoft.Surface.Presentation.Design.dll: the manifest may not be valid or the file could not be opened. - Source: System.Deployment - Stack trace: at System.Deployment.Application.Manifest.AssemblyManifest.ManifestLoadExceptionHelper(Exception exception, String filePath) at System.Deployment.Application.Manifest.AssemblyManifest.LoadFromInternalManifestFile(String filePath) at System.Deployment.Application.FileDownloader.AddFilesInHashtable(Hashtable hashtable, AssemblyManifest applicationManifest, String applicationFolder) --- Inner Exception --- System.Deployment.Application.DeploymentException (InvalidManifest) - Cannot load internal manifest from component file. - Source: - Stack trace: * [20/05/2010 09:17:40] System.Deployment.Application.InvalidDeploymentException (ManifestLoad) - Exception occurred loading manifest from file GalaSoft.MvvmLight.WPF4.dll: the manifest may not be valid or the file could not be opened. - Source: System.Deployment - Stack trace: at System.Deployment.Application.Manifest.AssemblyManifest.ManifestLoadExceptionHelper(Exception exception, String filePath) at System.Deployment.Application.Manifest.AssemblyManifest.LoadFromInternalManifestFile(String filePath) at System.Deployment.Application.FileDownloader.AddFilesInHashtable(Hashtable hashtable, AssemblyManifest applicationManifest, String applicationFolder) --- Inner Exception --- System.Deployment.Application.DeploymentException (InvalidManifest) - Cannot load internal manifest from component file. - Source: - Stack trace: * [20/05/2010 09:17:40] System.Deployment.Application.InvalidDeploymentException (ManifestLoad) - Exception occurred loading manifest from file Graphicly.Infrastructure.dll: the manifest may not be valid or the file could not be opened. - Source: System.Deployment - Stack trace: at System.Deployment.Application.Manifest.AssemblyManifest.ManifestLoadExceptionHelper(Exception exception, String filePath) at System.Deployment.Application.Manifest.AssemblyManifest.LoadFromInternalManifestFile(String filePath) at System.Deployment.Application.FileDownloader.AddFilesInHashtable(Hashtable hashtable, AssemblyManifest applicationManifest, String applicationFolder) --- Inner Exception --- System.Deployment.Application.DeploymentException (InvalidManifest) - Cannot load internal manifest from component file. - Source: - Stack trace: * [20/05/2010 09:17:40] System.Deployment.Application.InvalidDeploymentException (ManifestLoad) - Exception occurred loading manifest from file Graphicly.AutoUpdater.dll: the manifest may not be valid or the file could not be opened. - Source: System.Deployment - Stack trace: at System.Deployment.Application.Manifest.AssemblyManifest.ManifestLoadExceptionHelper(Exception exception, String filePath) at System.Deployment.Application.Manifest.AssemblyManifest.LoadFromInternalManifestFile(String filePath) at System.Deployment.Application.FileDownloader.AddFilesInHashtable(Hashtable hashtable, AssemblyManifest applicationManifest, String applicationFolder) --- Inner Exception --- System.Deployment.Application.DeploymentException (InvalidManifest) - Cannot load internal manifest from component file. - Source: - Stack trace: * [20/05/2010 09:17:40] System.Deployment.Application.InvalidDeploymentException (ManifestLoad) - Exception occurred loading manifest from file System.Windows.Interactivity.dll: the manifest may not be valid or the file could not be opened. - Source: System.Deployment - Stack trace: at System.Deployment.Application.Manifest.AssemblyManifest.ManifestLoadExceptionHelper(Exception exception, String filePath) at System.Deployment.Application.Manifest.AssemblyManifest.LoadFromInternalManifestFile(String filePath) at System.Deployment.Application.FileDownloader.AddFilesInHashtable(Hashtable hashtable, AssemblyManifest applicationManifest, String applicationFolder) --- Inner Exception --- System.Deployment.Application.DeploymentException (InvalidManifest) - Cannot load internal manifest from component file. - Source: - Stack trace: * [20/05/2010 09:17:40] System.Deployment.Application.InvalidDeploymentException (ManifestLoad) - Exception occurred loading manifest from file Microsoft.Surface.Presentation.dll: the manifest may not be valid or the file could not be opened. - Source: System.Deployment - Stack trace: at System.Deployment.Application.Manifest.AssemblyManifest.ManifestLoadExceptionHelper(Exception exception, String filePath) at System.Deployment.Application.Manifest.AssemblyManifest.LoadFromInternalManifestFile(String filePath) at System.Deployment.Application.FileDownloader.AddFilesInHashtable(Hashtable hashtable, AssemblyManifest applicationManifest, String applicationFolder) --- Inner Exception --- System.Deployment.Application.DeploymentException (InvalidManifest) - Cannot load internal manifest from component file. - Source: - Stack trace: * [20/05/2010 09:17:40] System.Deployment.Application.InvalidDeploymentException (ManifestLoad) - Exception occurred loading manifest from file Graphicly.Fonts.dll: the manifest may not be valid or the file could not be opened. - Source: System.Deployment - Stack trace: at System.Deployment.Application.Manifest.AssemblyManifest.ManifestLoadExceptionHelper(Exception exception, String filePath) at System.Deployment.Application.Manifest.AssemblyManifest.LoadFromInternalManifestFile(String filePath) at System.Deployment.Application.FileDownloader.AddFilesInHashtable(Hashtable hashtable, AssemblyManifest applicationManifest, String applicationFolder) --- Inner Exception --- System.Deployment.Application.DeploymentException (InvalidManifest) - Cannot load internal manifest from component file. - Source: - Stack trace: * [20/05/2010 09:17:40] System.Deployment.Application.InvalidDeploymentException (ManifestLoad) - Exception occurred loading manifest from file Graphicly.Reader.dll: the manifest may not be valid or the file could not be opened. - Source: System.Deployment - Stack trace: at System.Deployment.Application.Manifest.AssemblyManifest.ManifestLoadExceptionHelper(Exception exception, String filePath) at System.Deployment.Application.Manifest.AssemblyManifest.LoadFromInternalManifestFile(String filePath) at System.Deployment.Application.FileDownloader.AddFilesInHashtable(Hashtable hashtable, AssemblyManifest applicationManifest, String applicationFolder) --- Inner Exception --- System.Deployment.Application.DeploymentException (InvalidManifest) - Cannot load internal manifest from component file. - Source: - Stack trace: * [20/05/2010 09:17:40] System.Deployment.Application.InvalidDeploymentException (ManifestLoad) - Exception occurred loading manifest from file Microsoft.Surface.Presentation.Generic.dll: the manifest may not be valid or the file could not be opened. - Source: System.Deployment - Stack trace: at System.Deployment.Application.Manifest.AssemblyManifest.ManifestLoadExceptionHelper(Exception exception, String filePath) at System.Deployment.Application.Manifest.AssemblyManifest.LoadFromInternalManifestFile(String filePath) at System.Deployment.Application.FileDownloader.AddFilesInHashtable(Hashtable hashtable, AssemblyManifest applicationManifest, String applicationFolder) --- Inner Exception --- System.Deployment.Application.DeploymentException (InvalidManifest) - Cannot load internal manifest from component file. - Source: - Stack trace: * [20/05/2010 09:17:41] System.Deployment.Application.InvalidDeploymentException (ManifestLoad) - Exception occurred loading manifest from file Graphicly.Controls.dll: the manifest may not be valid or the file could not be opened. - Source: System.Deployment - Stack trace: at System.Deployment.Application.Manifest.AssemblyManifest.ManifestLoadExceptionHelper(Exception exception, String filePath) at System.Deployment.Application.Manifest.AssemblyManifest.LoadFromInternalManifestFile(String filePath) at System.Deployment.Application.FileDownloader.AddFilesInHashtable(Hashtable hashtable, AssemblyManifest applicationManifest, String applicationFolder) --- Inner Exception --- System.Deployment.Application.DeploymentException (InvalidManifest) - Cannot load internal manifest from component file. - Source: - Stack trace: * [20/05/2010 09:17:41] System.Deployment.Application.InvalidDeploymentException (ManifestLoad) - Exception occurred loading manifest from file Graphicly.SocialNetwork.dll: the manifest may not be valid or the file could not be opened. - Source: System.Deployment - Stack trace: at System.Deployment.Application.Manifest.AssemblyManifest.ManifestLoadExceptionHelper(Exception exception, String filePath) at System.Deployment.Application.Manifest.AssemblyManifest.LoadFromInternalManifestFile(String filePath) at System.Deployment.Application.FileDownloader.AddFilesInHashtable(Hashtable hashtable, AssemblyManifest applicationManifest, String applicationFolder) --- Inner Exception --- System.Deployment.Application.DeploymentException (InvalidManifest) - Cannot load internal manifest from component file. - Source: - Stack trace: * [20/05/2010 09:17:41] System.Deployment.Application.InvalidDeploymentException (ManifestLoad) - Exception occurred loading manifest from file Graphicly.Archive.dll: the manifest may not be valid or the file could not be opened. - Source: System.Deployment - Stack trace: at System.Deployment.Application.Manifest.AssemblyManifest.ManifestLoadExceptionHelper(Exception exception, String filePath) at System.Deployment.Application.Manifest.AssemblyManifest.LoadFromInternalManifestFile(String filePath) at System.Deployment.Application.FileDownloader.AddFilesInHashtable(Hashtable hashtable, AssemblyManifest applicationManifest, String applicationFolder) --- Inner Exception --- System.Deployment.Application.DeploymentException (InvalidManifest) - Cannot load internal manifest from component file. - Source: - Stack trace: * [20/05/2010 09:17:41] System.Deployment.Application.InvalidDeploymentException (ManifestLoad) - Exception occurred loading manifest from file Graphicly.App.exe: the manifest may not be valid or the file could not be opened. - Source: System.Deployment - Stack trace: at System.Deployment.Application.Manifest.AssemblyManifest.ManifestLoadExceptionHelper(Exception exception, String filePath) at System.Deployment.Application.Manifest.AssemblyManifest.LoadFromInternalManifestFile(String filePath) at System.Deployment.Application.FileDownloader.AddFilesInHashtable(Hashtable hashtable, AssemblyManifest applicationManifest, String applicationFolder) --- Inner Exception --- System.Deployment.Application.DeploymentException (InvalidManifest) - Cannot load internal manifest from component file. - Source: - Stack trace: * [20/05/2010 09:17:41] System.Deployment.Application.InvalidDeploymentException (ManifestLoad) - Exception occurred loading manifest from file GalaSoft.MvvmLight.Extras.WPF4.dll: the manifest may not be valid or the file could not be opened. - Source: System.Deployment - Stack trace: at System.Deployment.Application.Manifest.AssemblyManifest.ManifestLoadExceptionHelper(Exception exception, String filePath) at System.Deployment.Application.Manifest.AssemblyManifest.LoadFromInternalManifestFile(String filePath) at System.Deployment.Application.FileDownloader.AddFilesInHashtable(Hashtable hashtable, AssemblyManifest applicationManifest, String applicationFolder) --- Inner Exception --- System.Deployment.Application.DeploymentException (InvalidManifest) - Cannot load internal manifest from component file. - Source: - Stack trace: * [20/05/2010 09:17:41] System.Deployment.Application.InvalidDeploymentException (ManifestLoad) - Exception occurred loading manifest from file GalaSoft.MvvmLight.Extras.WPF4.dll: the manifest may not be valid or the file could not be opened. - Source: System.Deployment - Stack trace: at System.Deployment.Application.Manifest.AssemblyManifest.ManifestLoadExceptionHelper(Exception exception, String filePath) at System.Deployment.Application.Manifest.AssemblyManifest.LoadFromInternalManifestFile(String filePath) at System.Deployment.Application.DownloadManager.ProcessDownloadedFile(Object sender, DownloadEventArgs e) at System.Deployment.Application.FileDownloader.DownloadModifiedEventHandler.Invoke(Object sender, DownloadEventArgs e) at System.Deployment.Application.FileDownloader.PatchSingleFile(DownloadQueueItem item, Hashtable dependencyTable) at System.Deployment.Application.FileDownloader.PatchFiles(SubscriptionState subState) at System.Deployment.Application.FileDownloader.Download(SubscriptionState subState) at System.Deployment.Application.DownloadManager.DownloadDependencies(SubscriptionState subState, AssemblyManifest deployManifest, AssemblyManifest appManifest, Uri sourceUriBase, String targetDirectory, String group, IDownloadNotification notification, DownloadOptions options) at System.Deployment.Application.ApplicationActivator.DownloadApplication(SubscriptionState subState, ActivationDescription actDesc, Int64 transactionId, TempDirectory& downloadTemp) at System.Deployment.Application.ApplicationActivator.InstallApplication(SubscriptionState& subState, ActivationDescription actDesc) at System.Deployment.Application.ApplicationActivator.PerformDeploymentActivation(Uri activationUri, Boolean isShortcut, String textualSubId, String deploymentProviderUrlFromExtension, BrowserSettings browserSettings, String& errorPageUrl) at System.Deployment.Application.ApplicationActivator.ActivateDeploymentWorker(Object state) --- Inner Exception --- System.Deployment.Application.DeploymentException (InvalidManifest) - Cannot load internal manifest from component file. - Source: - Stack trace: COMPONENT STORE TRANSACTION DETAILS No transaction information is available. I'm baffled. Any ideas what this could be? Cheers Tony

    Read the article

  • @CodeStock 2012 Review: Jay Harris ( @jayharris ) - XCopy is Dead: .Net Deployment Strategies that Work

    XCopy is Dead: .Net Deployment Strategies that WorkSpeaker: Jay HarrisTwitter: @jayharrisBlog: www.cptloadtest.com This talk focused on new technologies built in to deployment packaging through Visual Studios 2010.  Jay showed various methodologies in deploying web sites, and focused on features specifically for Visual Studios 2010. He covered transforming config files based on environmental constraints, the creation of deployment packages, and deploying packages via command line or importing into IIS 7.

    Read the article

  • Java web app deployment and ControlTier adoption

    - by Ran
    I've been searching for a configuration and deployment manager tool for my java-linux based web service and have been looking mainly at ControlTier (http://controltier.org). We operate at a medium scale (100's of hosts, multi-DC, dozens of services). There seem to be be plenty of lower level system admin tools such as chef, puppet, cfengine, bcfg2 and more and my understanding and the reason I'm calling them "low level" is that they are great for system level administration tasks such as setting up a mount, file permissions, users etc but aren't designed, for example for java deployments, which usually come with a build process and special java semantics. In many cases any tool can be used to do anything but if it was not designed for the task it can get uncomfortable. OTOH control-tier seem to have been designed just for that - java application deployments, at least that's what all the tutorials on their site demonstrate but here's the problem - The wiki at http://controltier.org/wiki/ is pretty good and stuffed with examples and the company behind the open source CT product is very responsive (pushy...) however, I'm yet to have seen any material from 3rd party users on the net. No success stories, no detailed blog posts, no best practices, no cheat sheets, not even hate letters, nothing. This plays badly for DTO solutions, CT's sponsor for two reasons, one is that it makes me suspicious what's the reason for the poor adoption? and second, what do I do if I get stuck and there's no help page on CT's wiki page and the mailing list is too slow to answer. I'm stuck with a "free" product that a consultancy company is pushing. So my question here - I'd be interested in hearing if anyone has had real world experience with CT for java based web app deployments and if he'd thumb up the product? Any other comments that may enlighten me are welcome of course...

    Read the article

  • @CodeStock 2012 Review: Jay Harris ( @jayharris ) - XCopy is Dead: .Net Deployment Strategies that Work

    XCopy is Dead: .Net Deployment Strategies that WorkSpeaker: Jay HarrisTwitter: @jayharrisBlog: www.cptloadtest.com This talk focused on new technologies built in to deployment packaging through Visual Studios 2010.  Jay showed various methodologies in deploying web sites, and focused on features specifically for Visual Studios 2010. He covered transforming config files based on environmental constraints, the creation of deployment packages, and deploying packages via command line or importing into IIS 7.

    Read the article

  • CI Deployment Of Azure Web Roles Using TeamCity

    - by srkirkland
    After recently migrating an important new website to use Windows Azure “Web Roles” I wanted an easier way to deploy new versions to the Azure Staging environment as well as a reliable process to rollback deployments to a certain “known good” source control commit checkpoint.  By configuring our JetBrains’ TeamCity CI server to utilize Windows Azure PowerShell cmdlets to create new automated deployments, I’ll show you how to take control of your Azure publish process. Step 0: Configuring your Azure Project in Visual Studio Before we can start looking at automating the deployment, we should make sure manual deployments from Visual Studio are working properly.  Detailed information for setting up deployments can be found at http://msdn.microsoft.com/en-us/library/windowsazure/ff683672.aspx#PublishAzure or by doing some quick Googling, but the basics are as follows: Install the prerequisite Windows Azure SDK Create an Azure project by right-clicking on your web project and choosing “Add Windows Azure Cloud Service Project” (or by manually adding that project type) Configure your Role and Service Configuration/Definition as desired Right-click on your azure project and choose “Publish,” create a publish profile, and push to your web role You don’t actually have to do step #4 and create a publish profile, but it’s a good exercise to make sure everything is working properly.  Once your Windows Azure project is setup correctly, we are ready to move on to understanding the Azure Publish process. Understanding the Azure Publish Process The actual Windows Azure project is fairly simple at its core—it builds your dependent roles (in our case, a web role) against a specific service and build configuration, and outputs two files: ServiceConfiguration.Cloud.cscfg: This is just the file containing your package configuration info, for example Instance Count, OsFamily, ConnectionString and other Setting information. ProjectName.Azure.cspkg: This is the package file that contains the guts of your deployment, including all deployable files. When you package your Azure project, these two files will be created within the directory ./[ProjectName].Azure/bin/[ConfigName]/app.publish/.  If you want to build your Azure Project from the command line, it’s as simple as calling MSBuild on the “Publish” target: msbuild.exe /target:Publish Windows Azure PowerShell Cmdlets The last pieces of the puzzle that make CI automation possible are the Azure PowerShell Cmdlets (http://msdn.microsoft.com/en-us/library/windowsazure/jj156055.aspx).  These cmdlets are what will let us create deployments without Visual Studio or other user intervention. Preparing TeamCity for Azure Deployments Now we are ready to get our TeamCity server setup so it can build and deploy Windows Azure projects, which we now know requires the Azure SDK and the Windows Azure PowerShell Cmdlets. Installing the Azure SDK is easy enough, just go to https://www.windowsazure.com/en-us/develop/net/ and click “Install” Once this SDK is installed, I recommend running a test build to make sure your project is building correctly.  You’ll want to setup your build step using MSBuild with the “Publish” target against your solution file.  Mine looks like this: Assuming the build was successful, you will now have the two *.cspkg and *cscfg files within your build directory.  If the build was red (failed), take a look at the build logs and keep an eye out for “unsupported project type” or other build errors, which will need to be addressed before the CI deployment can be completed. With a successful build we are now ready to install and configure the Windows Azure PowerShell Cmdlets: Follow the instructions at http://msdn.microsoft.com/en-us/library/windowsazure/jj554332 to install the Cmdlets and configure PowerShell After installing the Cmdlets, you’ll need to get your Azure Subscription Info using the Get-AzurePublishSettingsFile command. Store the resulting *.publishsettings file somewhere you can get to easily, like C:\TeamCity, because you will need to reference it later from your deploy script. Scripting the CI Deploy Process Now that the cmdlets are installed on our TeamCity server, we are ready to script the actual deployment using a TeamCity “PowerShell” build runner.  Before we look at any code, here’s a breakdown of our deployment algorithm: Setup your variables, including the location of the *.cspkg and *cscfg files produced in the earlier MSBuild step (remember, the folder is something like [ProjectName].Azure/bin/[ConfigName]/app.publish/ Import the Windows Azure PowerShell Cmdlets Import and set your Azure Subscription information (this is basically your authentication/authorization step, so protect your settings file Now look for a current deployment, and if you find one Upgrade it, else Create a new deployment Pretty simple and straightforward.  Now let’s look at the code (also available as a gist here: https://gist.github.com/3694398): $subscription = "[Your Subscription Name]" $service = "[Your Azure Service Name]" $slot = "staging" #staging or production $package = "[ProjectName]\bin\[BuildConfigName]\app.publish\[ProjectName].cspkg" $configuration = "[ProjectName]\bin\[BuildConfigName]\app.publish\ServiceConfiguration.Cloud.cscfg" $timeStampFormat = "g" $deploymentLabel = "ContinuousDeploy to $service v%build.number%"   Write-Output "Running Azure Imports" Import-Module "C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\Azure\*.psd1" Import-AzurePublishSettingsFile "C:\TeamCity\[PSFileName].publishsettings" Set-AzureSubscription -CurrentStorageAccount $service -SubscriptionName $subscription   function Publish(){ $deployment = Get-AzureDeployment -ServiceName $service -Slot $slot -ErrorVariable a -ErrorAction silentlycontinue   if ($a[0] -ne $null) { Write-Output "$(Get-Date -f $timeStampFormat) - No deployment is detected. Creating a new deployment. " } if ($deployment.Name -ne $null) { #Update deployment inplace (usually faster, cheaper, won't destroy VIP) Write-Output "$(Get-Date -f $timeStampFormat) - Deployment exists in $servicename. Upgrading deployment." UpgradeDeployment } else { CreateNewDeployment } }   function CreateNewDeployment() { write-progress -id 3 -activity "Creating New Deployment" -Status "In progress" Write-Output "$(Get-Date -f $timeStampFormat) - Creating New Deployment: In progress"   $opstat = New-AzureDeployment -Slot $slot -Package $package -Configuration $configuration -label $deploymentLabel -ServiceName $service   $completeDeployment = Get-AzureDeployment -ServiceName $service -Slot $slot $completeDeploymentID = $completeDeployment.deploymentid   write-progress -id 3 -activity "Creating New Deployment" -completed -Status "Complete" Write-Output "$(Get-Date -f $timeStampFormat) - Creating New Deployment: Complete, Deployment ID: $completeDeploymentID" }   function UpgradeDeployment() { write-progress -id 3 -activity "Upgrading Deployment" -Status "In progress" Write-Output "$(Get-Date -f $timeStampFormat) - Upgrading Deployment: In progress"   # perform Update-Deployment $setdeployment = Set-AzureDeployment -Upgrade -Slot $slot -Package $package -Configuration $configuration -label $deploymentLabel -ServiceName $service -Force   $completeDeployment = Get-AzureDeployment -ServiceName $service -Slot $slot $completeDeploymentID = $completeDeployment.deploymentid   write-progress -id 3 -activity "Upgrading Deployment" -completed -Status "Complete" Write-Output "$(Get-Date -f $timeStampFormat) - Upgrading Deployment: Complete, Deployment ID: $completeDeploymentID" }   Write-Output "Create Azure Deployment" Publish   Creating the TeamCity Build Step The only thing left is to create a second build step, after your MSBuild “Publish” step, with the build runner type “PowerShell”.  Then set your script to “Source Code,” the script execution mode to “Put script into PowerShell stdin with “-Command” arguments” and then copy/paste in the above script (replacing the placeholder sections with your values).  This should look like the following:   Wrap Up After combining the MSBuild /target:Publish step (which creates the necessary Windows Azure *.cspkg and *.cscfg files) and a PowerShell script step which utilizes the Azure PowerShell Cmdlets, we have a fully deployable build configuration in TeamCity.  You can configure this step to run whenever you’d like using build triggers – for example, you could even deploy whenever a new master branch deploy comes in and passes all required tests. In the script I’ve hardcoded that every deployment goes to the Staging environment on Azure, but you could deploy straight to Production if you want to, or even setup a deployment configuration variable and set it as desired. After your TeamCity Build Configuration is complete, you’ll see something that looks like this: Whenever you click the “Run” button, all of your code will be compiled, published, and deployed to Windows Azure! One additional enormous benefit of automating the process this way is that you can easily deploy any specific source control changeset by clicking the little ellipsis button next to "Run.”  This will bring up a dialog like the one below, where you can select the last change to use for your deployment.  Since Azure Web Role deployments don’t have any rollback functionality, this is a critical feature.   Enjoy!

    Read the article

  • Error launching application after ClickOnce deployment - "An application for this deployment is alre

    - by digiduck
    As part of my continuous integration build the application is deployed as a ClickOnce application. This works great the first time, but when I try the launch the app after an update has been deployed I get the following error. An application for this deployment is already installed with a different application identity. If I run mage.exe -cc to clear the application cache for all ClickOnce apps then I can launch the application just fine. Has anyone run into this before? How can I fix this? Here are the steps in my build script that publish the ClickOnce application. ./tools/windows_sdk/mage.exe -New Application -Processor msil -ToFile "C:\temp\build\RoadrunnerTrap.exe.manifest" -Name "Roadrunner Trap" -Version 1.0.0.1 -FromDirectory "C:\temp\build" # artifacts from C:\temp\build\ are copied to \\server\publish\v1.0.0.1\ ./tools/windows_sdk/mage.exe -New Deployment -Processor msil -Install false -Publisher "Acme, Inc." -ProviderUrl "\\server\publish\RoadrunnerTrap.application" -Name "Roadrunner Trap" -AppManifest "\\server\publish\v1.0.0.1\RoadrunnerTrap.exe.manifest" -ToFile "\\server\publish\RoadrunnerTrap.application" Note that the version number does change with every deployment.

    Read the article

  • Using Deployment Manager

    - by Jess Nickson
    One of the teams at Red Gate has been working very hard on a new product: Deployment Manager. Deployment Manager is a free tool that lets you deploy updates to .NET apps, services and databases through a central dashboard. Deployment Manager has been out for a while, but I must admit that even though I work in the same building, until now I hadn’t even looked at it. My job at Red Gate is to develop and maintain some of our community sites, which involves carrying out regular deployments. One of the projects I have to deploy on a fairly regular basis requires me to send my changes to our build server, TeamCity. The output is a Zip file of the build. I then have to go and find this file, copy it across to the staging machine, extract it, and copy some of the sub-folders to other places. In order to keep track of what builds are running, I need to rename the folders accordingly. However, even after all that, I still need to go and update the site and its applications in IIS to point at these new builds. Oh, and then, I have to repeat the process when I deploy on production. Did I mention the multiple configuration files that then need updating as well? Manually? The whole process can take well over half an hour. I’m ready to try out a new process. Deployment Manager is designed to massively simplify the deployment processes from what could be lots of manual copying of files, managing of configuration files, and database upgrades down to a few clicks. It’s a big promise, but I decided to try out this new tool on one of the smaller ASP.NET sites at Red Gate, Format SQL (the result of a Red Gate Down Tools week). I wanted to add some new functionality, but given it was a new site with no set way of doing things, I was reluctant to have to manually copy files around servers. I decided to use this opportunity as a chance to set the site up on Deployment Manager and check out its functionality. What follows is a guide on how to get set up with Deployment Manager, a brief overview of its features, and what I thought of the experience. To follow along with the instructions that follow, you’ll first need to download Deployment Manager from Red Gate. It has a free ‘Starter Edition’ which allows you to create up to 5 projects and agents (machines you deploy to), so it’s really easy to get up and running with a fully-featured version. The Initial Set Up After installing the product and setting it up using the administration tool it provides, I launched Deployment Manager by going to the URL and port I had set it to run on. This loads up the main dashboard. The dashboard does a good job of guiding me through the process of getting started, beginning with a prompt to create some environments. 1. Setting up Environments The dashboard informed me that I needed to add new ‘Environments’, which are essentially ways of grouping the machines you want to deploy to. The environments that get added will show up on the main dashboard. I set up two such environments for this project: ‘staging’ and ‘live’.   2. Add Target Machines Once I had created the environments, I was ready to add ‘target machine’s to them, which are the actual machines that the deployment will occur on.   To enable me to deploy to a new machine, I needed to download and install an Agent on it. The ‘Add target machine’ form on the ‘Environments’ page helpfully provides a link for downloading an Agent.   Once the agent has been installed, it is just a case of copying the server key to the agent, and the agent key to the server, to link them up.   3. Run Health Check If, after adding your new target machine, the ‘Status’ flags an error, it is possible that the Agent and Server keys have not been entered correctly on both Deployment Manager and the Agent service.     You can ‘Check Health’, which will give you more information on any issues. It is probably worth running this regardless of what status the ‘Environments’ dashboard is claiming, just to be on the safe side.     4. Add Projects Going back to the main Dashboard tab at this point, I found that it was telling me that I needed to set up a new project.   I clicked the ‘project’ link to get started, gave my new project a name and clicked ‘Create’. I was then redirected to the ‘Steps’ page for the project under the Projects tab.   5. Package Steps The ‘Steps’ page was fairly empty when it first loaded.   Adding a ‘step’ allowed me to specify what packages I wanted to grab for the deployment. This part requires a NuGet package feed to be set up, which is where Deployment Manager will look for the packages. At Red Gate, we already have one set up, so I just needed to tell Deployment Manager about it. Don’t worry; there is a nice guide included on how to go about doing all of this on the ‘Package Feeds’ page in ‘Settings’, if you need any help with setting these bits up.    At Red Gate we use a build server, TeamCity, which is capable of publishing built projects to the NuGet feed we use. This makes the workflow for Format SQL relatively simple: when I commit a change to the project, the build server is configured to grab those changes, build the project, and spit out a new NuGet package to the Red Gate NuGet package feed. My ‘package step’, therefore, is set up to look for this package on our feed. The final part of package step was simply specifying which machines from what environments I wanted to be able to deploy the project to.     Format SQL Now the main Dashboard showed my new project and environment in a rather empty looking grid. Clicking on my project presented me with a nice little message telling me that I am now ready to create my first release!   Create a release Next I clicked on the ‘Create release’ button in the Projects tab. If your feeds and package step(s) were set up correctly, then Deployment Manager will automatically grab the latest version of the NuGet package that you want to deploy. As you can see here, it was able to pick up the latest build for Format SQL and all I needed to do was enter a version number and description of the release.   As you can see underneath ‘Version number’, it keeps track of what version the previous release was given. Clicking ‘Create’ created the release and redirected me to a summary of it where I could check the details before deploying.   I clicked ‘Deploy this release’ and chose the environment I wanted to deploy to and…that’s it. Deployment Manager went off and deployed it for me.   Once I clicked ‘Deploy release’, Deployment Manager started to automatically update and provide continuing feedback about the process. If any errors do arise, then I can expand the results to see where it went wrong. That’s it, I’m done! Keep in mind, if you hit errors with the deployment itself then it is possible to view the log output to try and determine where these occurred. You can keep expanding the logs to narrow down the problem. The screenshot below is not from my Format SQL deployment, but I thought I’d post one to demonstrate the logging output available. Features One of the best bits of Deployment Manager for me is the ability to very, very easily deploy the same release to multiple machines. Deploying this same release to production was just a case of selecting the deployment and choosing the ‘live’ environment as the place to deploy to. Following on from this is the fact that, as Deployment Manager keeps track of all of your releases, it is extremely easy to roll back to a previous release if anything goes pear-shaped! You can view all your previous releases and select one to re-deploy. I needed this feature more than once when differences in my production and staging machines lead to some odd behavior.     Another option is to use the TeamCity integration available. This enables you to set Deployment Manager up so that it will automatically create releases and deploy these to an environment directly from TeamCity, meaning that you can always see the latest version up and running without having to do anything. Machine Specific Deployments ‘What about custom configuration files?’ I hear you shout. Certainly, it was one of my concerns. Our setup on the staging machine is not in line with that on production. What this means is that, should we deploy the same configuration to both, one of them is going to break. Thankfully, it turns out that Deployment Manager can deal with this. Given I had environments ‘staging’ and ‘live’, and that staging used the project’s web.config file, while production (‘live’) required the config file to undergo some transformations, I simply added a web.live.config file in the project, so that it would be included as part of the NuGet package. In this file, I wrote the XML document transformations I needed and Deployment Manager took care of the rest. Another option is to set up ‘variables’ for your project, which allow you to specify key-value pairs for your configuration file, and which environment to apply them to. You’ll find Variables as a full left-hand submenu within the ‘Projects’ tab. These features will definitely be of interest if you have a large number of environments! There are still many other features that I didn’t get a chance to play around with like running PowerShell scripts for more personalised deployments. Maybe next time! Also, let’s not forget that my use case in this article is a very simple one – deploying a single package. I don’t believe that all projects will be equally as simple, but I already appreciate how much easier Deployment Manager could make my life. I look forward to the possibility of moving our other sites over to Deployment Manager in the near future.   Conclusion In this article I have described the steps involved in setting up and configuring an instance of Deployment Manager, creating a new automated deployment process, and using this to actually carry out a deployment. I’ve tried to mention some of the features I found particularly useful, such as error logging, easy release management allowing you to deploy the same release multiple times, and configuration file transformations. If I had to point out one issue, then it would be that the releases are immutable, which from a development point of view makes sense. However, this causes confusion where I have to create a new release to deploy to a newly set up environment – I cannot simply deploy an old release onto a new environment, the whole release needs to be recreated. I really liked how easy it was to get going with the product. Setting up Format SQL and making a first deployment took very little time. Especially when you compare it to how long it takes me to manually deploy the other site, as I described earlier. I liked how it let me know what I needed to do next, with little messages flagging up that I needed to ‘create environments’ or ‘add some deployment steps’ before I could continue. I found the dashboard incredibly convenient. As the number of projects and environments increase, it might become awkward to try and search them and find out what state they are in. Instead, the dashboard handily keeps track of the latest deployments of each project and lets you know what version is running on each of the environments, and when that deployment occurred. Finally, do you remember my complaint about having to rename folders so that I could keep track of what build they came from? This is yet another thing that Deployment Manager takes care of for you. Each release is put into its own directory, which takes the name of whatever version number that release has, though these can be customised if necessary. If you’d like to take a look at Deployment Manager for yourself, then you can download it here.

    Read the article

  • Creating block devices for openstack deployment using MAAS and juju (nova-volume deployment)

    - by Tom Van Hoof
    Hi, I'm currently trying to get a openstack deployment working by using MAAS with 9 nodes and juju. To do this I found this guide, working with ubuntu 12.04 LTS https://help.ubuntu.com/community/UbuntuCloudInfrastructure and followed it as good as I can. After a vigorous amount of trial and error I finally got to the point where I'm supposed to deploy nova-volume using the "custom" config file. However when my node is started and shows up as running in the "juju status" report the service reports the installation failed. I'm trying to install with juju jitsu by the way. I think it has something to do with the following statement in the openstack.cfg file : nova-volume: # This must be a free block device that is writable on the nova-volume host. block-device: "xvdb" overwrite: "true" I did some research and found that (at least I think) this refers to a Xen Virtual Drive/device, and because the device is not present on the node it's being deployed to, the installation fails. What I don't understand is how I am supposed to have such a block device available on a machine which was completely managed by MAAS. Does anyone here have any experience with this and knows of a way to solve this, or am I missing something big here. Some kind of missing link between the MAAS and a separate XEN host ? My MAAS server is ubuntu 12.04LTS Server. All help is welcome. Kind regards, Tom

    Read the article

  • vs 2010 Deployment without Web Deploy

    - by dritterweg
    with vs 2008 I always used Web Deployment Project to build to three different environments. It is maybe not the best solution, since I still have to xcopy the built files to the server, but it is simple. now with vs 2010 it looks promising, but It looks also complicated. My hosting doesn't have Web Deploy, the newest feature and the flagship technology for deployment in vs2010. My question how can I just build for each environment and copy the files over to the server. Using the Build Deployment Package will create the zip file and when I extract it, it will output so many files and confusing folder structure. Anyone has suggestion?

    Read the article

  • Is there a recognized Deployment Process?

    - by Steve Griff
    Hello there, We have a decent deployment process for our web sites utilized in our company that works pretty well. I was wondering, is there a recognized, standard for deploying? Or is it a case of everyone having their own kind of deployment process that is built from their own experience and how the coding architecture is managed? Regards, Steve Griff

    Read the article

  • Deployment Setup (.Net) - Search target machine -> Registry search (64 bit)

    - by Joonas Kirsebom
    I have a windows installer project which installs some software (winform, service, mce addin). During the installation I need to search the machine for a registry key. This is done with with the "Launch Condition" - "Add Registry Search" (Deployment Project). I have filled out all the properties right, and checked against the regestry that the value actually can be found. The problem is that the "Registry Search" searches in the x86 part of the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\...) although my system is a x64 and the deployment setup is also set to x64. Does anyone know how to force the "Registry Search" to search the x64 registry? Or know about a workaround? The weird thing about this, is that Registry setting in the deployment setup is writing to the right registry (x64). My idea is that the "Registry Search" program is only developed to the x86 architecture, and therefore can't read the right registry. I found this article from microsoft, so it seams that they know about this problem. https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=110105&wa=wsignin1.0#details My system is: Windows 7 64bit Visual Studio 2008

    Read the article

  • Custom Profile Provider with Web Deployment Project

    - by Ben Griswold
    I wrote about implementing a custom profile provider inside of your ASP.NET MVC application yesterday. If you haven’t read the article, don’t sweat it.  Most of the stuff I write is rubbish anyway. Since you have joined me today, though, I might as well offer up a little tip: you can run into trouble, like I did, if you enable your custom profile provider inside of an application which is deployed using a Web Deployment Project.  Everything will run great on your local machine and you’ll probably take an early lunch because you got the code running in no time flat and the build server is happy and all tests pass and, gosh, maybe you’ll just cut out early because it is Friday after all.  But then the first user hits the integration machine and, that’s right, yellow screen of death. Lucky you, just as you’re walking out the door, the user kindly sends the exception message and stack trace: Value cannot be null. Parameter name: type Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Stack Trace: [ArgumentNullException: Value cannot be null. Parameter name: type] System.Activator.CreateInstance(Type type, Boolean nonPublic) +2796915 System.Web.Profile.ProfileBase.CreateMyInstance(String username, Boolean isAuthenticated) +76 System.Web.Profile.ProfileBase.Create(String username, Boolean isAuthenticated) +312 User error?  Not this time. Damn! One hour later… you notice the harmless “Treat as library component (remove the App_Code.compiled file)” setting on the Output Assemblies Tab of your Web Deployment Project. You have no idea why, but you uncheck it.  You test and everything works great both locally and on the integration machine.  Application users think you’re the best and you’re still going to catch the last half hour of happy hour.  Happy Friday.

    Read the article

  • AIA - Server Topologien und Deployment

    - by Hans Viehmann
    Es gibt ein neues White Paper, in dem die verschiedenen Varianten von AIA Topologien ausführlich beschrieben sind. Die unterschiedlichen Möglichkeiten ergeben sich vor allem aus dem Betrieb mehrerer AIA Instanzen parallel (z.B. Aufteilung in Dev/Test/Prod, Aufteilung zur Lastverteilung, Zuordnung zu unterschiedlichen Geografien, ...). Weitere Variationsmöglichkeiten bietet die Verteilung der unterschiedlichen Bestandteile des DB-Schemas (AIA Metadaten, Cross-Referencing Daten, AIA Lifecycle Repository, JMS Schema, etc.). Und schließlich können auch verschiedene Topologien der SOA Laufzeitumgebung, wie beispielsweise SOA Cluster, unterstützt werden. Diese Varianten mit ihren typischen Einsatzfeldern werden in dem Dokument ebenso beschrieben, wie deren Umsetzung mit Hilfe des Installers.In einem zweiten Teil befasst sich das White Paper mit dem Deployment der AIA Artefakte in diese Topologien, und zwar insbesondere mit dem Tool-Support durch die "Project Lifecycle Workbench" und dem "AIA Installation Driver". Erstere ist eine neue Komponente in AIA 11gR1, die in der Lage ist, am Ende des Entwicklungszyklus Deployment Pläne zu generieren, während der ebenfalls neue "AIA Installation Driver" dann die Artefakte dann in die Zielumgebung überträgt.Das White Paper ist noch nicht auf oracle.com verfügbar und ist leider so umfangreich, dass es nicht auf auf blogs.oracle.com hochgeladen werden kann. Bei Interesse verschicke ich es aber gern per Mail.

    Read the article

  • What deployment framework to use?

    - by jeruki
    We are trying to figure out what deployment method/framework to use with a python application, it has a basic wsgi server to make some REST resources available and a set of static web pages with the interface that are served through apache. The situation is as follows: My team works in isolated parts of the program and sometimes together in specific modules, we have different testing servers and one master server, we all work locally, sync the code using git, and then run a bash script that copies the files from the windows machines to the indicated linux server(using ssh) and then restarts the app. After thinking about it this doesn't seem to be the right way to do it, the script overwrites all the files in the server with the local files everytime. We want to be able to work in the same server without the worry of overwriting other people's code and we need to deploy to different servers to avoid restarting the service while others work with it and in the near future we need to deploy to the master or several clones of the master server when the application reaches a more mature state. We found serveral options capistrano, kwate, chef or fortress, even fleet but we wanted to have opinions from people that has used them to be sure it is what we need. So this are the main questions: Are these the kind of programs we should be looking at to achive a safe concurrent deployment process? Which one have you used/recommend and why? do you think it would help in our actual situation? Thank you so much for your feedback and advice on this.

    Read the article

1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >